IOS 14 Doorbell

Describe The Bug:
No doorbell button is displayed in HK. As an accessory in the home bridge is displayed.
To Reproduce:

Expected behavior:

Logs:

Show the Homebridge logs here.
Remove any sensitive information.

Homebridge Config:
"cameras": [
{
"name": "Домофон",
"manufacturer": "EZVIZ",
"doorbell": true,
"videoConfig": {
"source": "-rtsp_transport tcp -re -i rtsp://admin:admin@<IP_ADDRESS>:554/h264/ch01/sub/av_stream",
"stillImageSource": "-re -i rtsp://admin:admin@<IP_ADDRESS>:554/h264/ch01/sub/av_stream -vframes 1 -r 1",
"maxFPS": 30,
"vcodec": "copy",
"audio": true,
"debug": false
}
}
],
"platform": "Camera-ffmpeg"
},
Screenshots:

Environment:

Node.js Version: v12.18.2
NPM Version: v6.14.5
Homebridge Version: try on 1.1.1 now 1.2.0-beta.29
Homebridge Camera FFmpeg Version:v2.2.1
Homebridge Config UI X Plugin Version:v4.23.2
Operating System:Raspbian

Please share your config.

Please share your config.

Add to original post

Using that config, I do see a doorbell device being created on iOS 14 beta 2. You'll need to use another app besides Apple Home to see it. I recommend Eve to see everything that is in HomeKit.
If you're looking for some way to trigger the doorbell, you'll probably want to enable the switches config option.

Using that config, I do see a doorbell device being created on iOS 14 beta 2. You'll need to use another app besides Apple Home to see it. I recommend Eve to see everything that is in HomeKit.
If you're looking for some way to trigger the doorbell, you'll probably want to enable the switches config option.

I'd be grateful if you could tell me how having a physical hiaomi clip to make the doorbell in ffmpeg work. I have an EVE but I can't set it up.

It's basically like this, but with doorbell instead of motion: https://github.com/homebridge-plugins/homebridge-camera-ffmpeg/wiki/iOS-13-and-Photo-Notifications
I need to rewrite that page at some point to make it more clear.


User usability issues

[x] Height of the channel control list is not dynamic
[ ] Viewer app should deal with login issue - the viewer app on full screen shows No Slide Id if the user is not logged in, instead of giving an appropriate error message.
[x] Give spacing between each channel in the channel control so that the division between channels is more prominent.
[ ] When the channel is opened for the no-channel case, it starts with a big area, then shrinks and when the button is closed, it again expands before closing.
[ ] The left panel for annotations should move along with the title. Currently, the title is given a margin on page load and the left panel is shown after a while. Issue Link.

With the recent changes to both OSD viewer and Chaise viewer, all the mentioned issues have been resolved.


Fix PropType Error in RN 0.50.xx (React 16.xx)

Fix PropType Error in RN 0.50.xx (React 16.xx)

You should use version 2 of this library for use with RN 0.50 and up


[Docs] Correct ReadME

Current State:
The Readme for this repo shows Meshery adapter for KUMA
Desired State:
Make the correction to be NGINX Service Mesh

Contributor Resources

Meshery documentation site
Meshery documentation source
Instructions for contributing to documentation

@PluckyPrecious Just to check if I am getting it correct. Final heading will be Meshery Adapter for NGINX Service Mesh, right? or just NGINX Service Mesh

Meshery Adapter for NGINX Service Mesh


Implement connection timeout

Implement configurable timeout value when making requests to remote host. By default it's infinite.
https://stackoverflow.com/questions/11537591/resttemplate-default-timeout-value

Implemented in #43


Integration does not appear after installation

I installed this integration via HACS and restarted. It is visible in HACS. But it is not visible in Configuration - Integrations and I can not find it via Add integration button.

@luberan What's your HA version? And version of Jablotron integration?

Probably solved on Discord.


make docs readable in plain text again

Our docs used be quite readable in plain text, which, after all, is one of the reasons for using markdown. That is no longer the case, due to

overlong lines - we used to limit to 72 except for some code blocks
trailing whitespace

NB: We should either make this change now, before 1.5.0 is out, or later on the latest_release_doc_updates branch. Otherwise we will get loads of merge conflicts later when updating the live docs.


Remove Placeholder after calling PreDelete

PreDelete will perform a convert to Full
This requires we hydrate the file first, hence the call order changes in KauthHandler

resolves #951

The only comment I have is that it might be good to have a functional test for this? Or perhaps we already do but it's ignored on Mac so far?

My Rename PR has a bunch of tests that will hit this code path.  We also have good Delete tests here.  The one bit that hard to functional test is running as a different user (at least on windows).  Generally that becomes tricky for security reasons.

My Rename PR has a bunch of tests that will hit this code path. We also have good Delete tests here. The one bit that hard to functional test is running as a different user (at least on windows). Generally that becomes tricky for security reasons.

Yeah, I'm not suggesting testing all code paths via functional tests here, just making sure renaming an empty file now works correctly. (presumably it previously did not - otherwise what's this PR for?)

Yeah, I'm not suggesting testing all code paths via functional tests here, just making sure renaming an empty file now works correctly. (presumably it previously did not - otherwise what's this PR for?)

Great question!  The functionality worked before, the issue was we may try to hydrate twice (once for predelete and once for any other hydrating action).  Since we remove the flag now on predelete, it will only hydrate once.  It's a performance optimization.

@pmj @jeschu1

The functionality worked before, the issue was we may try to hydrate twice (once for predelete and once for any other hydrating action). Since we remove the flag now on predelete, it will only hydrate once. It's a performance optimization.

I don't think we would have hydrated twice before as the FileFlags_IsEmpty flag would have been cleared after the first hydration.
This PR gets us the first half of what's required for #606, and helps tighten up correctness a bit in rename scenarios.  The update placeholder helper functions should fail on a file that's been renamed, and we get that "failure after rename" behavior by removing the placeholder xattr.

Thanks for the explanations everyone. Looks like I’d misunderstood the purpose of the changes.


crdb: transaction resets

builds on top of #298

Closing in favor of #298 (only opened this when @samkim was out for a bit)


Add poly_complex_exp

Seems impossible to test in the same manner, as other two poly templates, due to precision error.

Yes, you're right. The proper way to test for equality is what you've done in this PR, you were just lucky with poly_real.


I don't understand what this repo is?

Why does it point to another repo which seems to do the same thing @afgane?

Also, why is this the slowest part of building an image using Bjoern's image? It takes at least 5 minutes per tool! Why is this so slow?

This is a playbook that just wraps the galaxy-tools role so the role can be used without the user needing to create the playbook to use the role and can instead clone this one. In the context of larger playbook, this playbook is not needed.
As far as the speed goes, it all depends on how long the specified tools take to install. When I run this on a toolset that's close to that of Main, it takes 2-3hrs for all the tools to install.

Is there a faster way to install tools using this playbook? Can you think of a better way than this?

The time it takes has nothing to do with the playbook, it's just how long the tools take to install so I don't think there's anything that can be done. One day in the desirable future, individual tools may be packaged as ready-to-use containers that we will simply be able to leverage but until then, they have to be built and that often takes time.

Alex, if your tools is available through conda, installation will be as fast as possible. So get your tool conda ready :-)
On Aug 29, 2016 10:21 PM, Enis Afgan<EMAIL_ADDRESS>wrote:The time it takes has nothing to do with the playbook, it's just how long the tools take to install so I don't think there's anything that can be done. One day in the desirable future, individual tools may be packaged as ready-to-use containers that we will simply be able to leverage but until then, they have to be built and that often takes time.
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.


[Suricata][Feature Request] Additional rule UI widgets for editing/sorting/filtering

There are a number of UI enhancements that would make the rule editor easier to use for more complex policies.

[ ]  A way to apply rules or filters to mark rules for dropping, sort of like oinkmaster rule files.

[ ]  A widget to respect the IPS policy mode metadata for Snort VRT rules (https://github.com/opnsense/core/issues/1869) to enable preselected rules for dropping (e.g., via "policy mode" and "policy selection" dropdowns as in pfSense's Suricata package).

[ ]  Filtering dropdowns for policy set and/or file

[ ]  Ability to filter based on enable status (e.g, show only disabled or enabled rules)

@shonjir

A way to apply rules or filters to mark rules for dropping, sort of like oinkmaster rule files.

you know you can change all rules in a file at once using "filter" in the download tab? or are you looking for something more fine-grained?

Definitely more fine-grained.  The per-ruleset method works well for the ET-open rules where most of the rules you'd want to set to drop are well grouped into distinct rulesets.
Snort rules aren't quite as accommodating, with rules of varying severities and desired actions mixed throughout.  More selection options would definitely help with these.
From a flexibility standpoint being able to set a baseline drop policy that's keyed to rule severity, classification, and/or policy metadata would be a great feature that would allow more flexibility in managing rulesets while retaining the "easy to use" aspect of OPNsense for the majority of users.
I was originally thinking in terms of oinkmaster configs (what I used with pfsense), but honestly a drop policy screen with a severity radio button, an IPS policy radio button, and a category checklist would allow a really simple way to customize rule actions without incurring the complexity of the oinkmaster method.
The screen could even include a rule action summary matrix showing counts of rules that are active/inactive, set to alert/drop, etc. as a way to provide immediate feedback when buttons are changed.

Timeout


App doesn't exit

The app doesn't have an exit buttom. If I want to disconect everything, I can't make the icon disapear from the notification area, unless I use a task killer.

@n8fr8 in which version is this fixed?


Setting XY Grid gutter to 0 breaks margin offset

What should happen?

Set the gutter value to 0
Include xy-cell-offset with offset value
The result should be something like:

    width: 66.66667%;
    margin-left: 16.66667%

What happens instead?
Outputs invalid declaration:
    width: 66.66667%;
    margin-left: calc(16.66667% + 0); // doesn't work with unitless number

Possible Solution
If value is 0, output property value without calc()
Test Case and/or Steps to Reproduce
Note - This test will not work in Codepen without having the mixins available so I've added the actual CSS rendered as well as my expected result.
Test Case: https://codepen.io/hexagoncircle/pen/3301fc285292192524930c01f3eab938/
Context
I need a grid without gutters. It would be preferred to set this up with the provided Sass mixins instead of using Foundation classes in HTML.
Your Environment

Foundation version(s) used: 6.5.0-rc.2
Browser(s) name and version(s): Chrome 68.0.3440.106

Checklist (all required):

[x] I have read and follow the CONTRIBUTING.md document.
[x] There are no other issues similar to this one.
[x] The issue title is descriptive.
[x] The template is correctly filled.

Hi @hexagoncircle 👋 ,
Thank you for the bug report. It has been resolved in https://github.com/zurb/foundation-sites/pull/11472. We were using the fix you suggested (not using calc) in the others mixins of the XY Grid, but not this one.
Feel free to review the pull request to ensure it is what you expected.

Thanks, @ncoden - that was fast! I have reviewed this locally and it works as expected.


Cmake

an additional build system, using cmake.  Should help folks build this on Windows (not like I have a Windows machine to test on).  Using this, folks can build Makefiles, XCode project files, or VS project files.  I build like:
cd libmill
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make

folks can do cmake -G Xcode .. or -G 'Visual Studio 14 2015 Win64'

Nice! Can you please state the patch is submitted under MIT license?

The 2 submitted patches and all subsequent patches I submit to this project are licensed under the current license of this project; which at this time is the MIT license.

oh, I forgot to build the stuff in perf.  Want me to add it here or in a follow up PR?

oops, also am not yet building a shared lib (was only building a static lib)

ok, I think this is good to go.  One thing I didn't check is that for the perf stuff I'm linking to the static lib, not the shared lib, so this might have performance implications (read improvements) if with the old build system you're linking against the shared lib.
Also, I think there's a way of generating a test harness similar to make check but I'll have to research that.
Finally, we should update the docs that you can also use cmake to build.

Thanks! If you want to improve the CMake build, one important thing is to use -O1 when building with clang. There's some kind of compiler bug there which makes it fail with -O2.

I was looking at the bug you have on file for that, #21 .  I cannot reproduce.  I'll post in there.
Note: with cmake, usually you either run cmake .. which generates a Makefile with optimizations off (you can check this with VERBOSE=1 make) or cmake -DCMAKE_BUILD_TYPE=Release .. which has -O3.


pundle exec should be similar to bundle exec

If I have a requirements.txt with requests in it and try to do
$ python -m pundle exec python
Python 2.7.12 (default, Jul  1 2016, 15:12:24)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests

it doesn't work. I see that pundle env does this, but why use a different command? Since pundler's meant to be a bundler clone, shouldn't pundle exec work similarly to bundle exec?
In bundler, if I have a Gemfile with sinatra in it, I can do
$ bundle exec ruby hello.rb

To run the app
Let me know if you think this makes sense, I may be able to contribute a PR

pundle env command is more descriptive on what it does — augment env with custom PYTHON_PATH.
pundle exec starts package scripts.
If you need console, try pundle console or pundle console (ipython|bpython|ptpython).
I'm not sure if we need to imitate bundler behaviour.


ipptool doesn't check that the printer's response contains a "Content-Type: application/ipp" header

Based on a packet trace, it seems like some printers do not include a "Content-Type: application/ipp" HTTP header in their responses, which is technically non-conformant.
ipptool should check for this and (at least) warn the user when in "test" mode.

[master d130c11] Add HTTP response header validation to ipptool (Issue #39)
Activated using the "-h" option...


implement in igo

When this is stable, can I implement it into my igo package (https://github.com/rocketlaunchr/igo)?

You're welcome to take this code and do whatever you like with it per the LICENSE file. Thanks.


Recommended fixes/changes to organizations

changes organization header gradient
changes various button tooltips
changes "view in dashboard" link
changes some of the placeholders
removes border highlight on non clickable table rows

The header gradient to me seems a bit off, I was initially thrown off by it when I had a quick look because I thought maybe something with the page rendered incorrectly

Some small issues/wording changes

On the manage page of the organzations UI when removing a user that has some manager level, the tooltip on the button should change from Delete user to Remove user as you aren't deleting the user from lagoon, you're removing their access to manage the organization.

Suggested wording:
This action will remove user default-user@ben-testing from management of the organization ben-test-org.

On the projects page of the organizations UI, when deleting a project, the message says it will delete it from the organization. This isn't entirely accurate, as it is a destructive action. The project is completely deleted from Lagoon, not just deleted from the organization.

Suggested wording?:
This action will delete project ben-testing from Lagoon and the organization.

@shreddedbacon @tobybellwood @CGoodwin90 I've tried numerous ways to include the <ErrorAlert /> component we use for cancelling deployment/task and in new environments.
The problem lies with either the <Mutation /> component from apollo, or react-modal that we use - multiple instances of errors get rendered; even if we limit the alert component to just one, the old instance gets destroyed and replaced with a new one, which ruins the UX.
Aside from that, I think this pr is good to go.


No way to drop samples which are longer than max_length in ORPOTrainer?

Unless I'm missing something there's no way to give it your dataset and then have it throw away anything that doesn't fit within max_length. It seems like you're forced to either;

Tokenize the samples yourself first to find which are too long, then throw them away before letting the ORPOTrainer deal with the samples that do fit.
Have ORPOTrainer truncate your samples which don't fit.

Preference training is already finicky, so trying to properly train a model when your original samples have data removed from them sounds like a recipe for disaster. It's also just not what I want to happen when I train. I'd much rather have less samples and know they are all exactly as I saved them in my dataset than have more samples and what they contain is completely different.
Is there any way or any plan to allow the samples to be dropped instead of truncated? Also I haven't looked at the other trainers so this might be an issue for them as well?

so the max_length is used to truncate the prompt+completions rather than remove them... I suppose if you need to remove them can't do that in the data-preparation stage?

That's what I mean. You have to setup your own way of filtering out the samples beforehand, when it would make more sense to have a flag to drop instead of truncate. The code is already checking sample length to decide if it needs to truncate, so the code could just be done there to drop the samples instead.


UNSUPPORTED_NODE: No importer registered for op: GridSampler

hello, thanks for you proj.
I all process the same as your Readme.md, but I still got UNSUPPORTED_NODE: No importer registered for op: GridSampler when run :  LD_PRELOAD=xxx/TensorRT/build/out/libnvinfer_plugin.so.7  python test_plugin_result.py

This error is reported by onnxparser. I will look into the the newly built libnvonnxparser.so, whether it's the updated one in your path.

Dear TrojanXu,
I am getting the same issue after following the installation readme.
Could you specfiy on what should I would need to do to fix the issue?


trying to write to kbfs

[write something useful and descriptive here]
first time, just installed and echo 'hello' > ~/keybase/public/voobofdoom/hello.txt
logs show
[WARN kbfs(PRE) prefetcher.go:683] 00b error prefetching block 0171eac9df95176e8337370fe932e0499e24f437780e28ab3b0677bd9d15c644d0: Couldn't get block 0171eac9df95176e8337370fe932e0499e24f437780e28ab3b0677bd9d15c644d0, canceling [tags:FBOID=Z0oR3KqflhmBXGe06bmSMA]

my log id: bfa21e2350abde4d04b6271c

That's expected.  In general our logs aren't very readable by non-devs, sorry about that.
If you are experiencing an actual error with reads or writes, please re-open.


Add support for gradient backgrounds

I propose to add &gradient=1 to make a background gradient, based on the background property, where the bottom will be a little darker, and the top a little brighter.
For example:

I'd gladly become a sponsor to support the development of this feature by the way!

Already solved this using our own implementation :)

Already solved this using our own implementation :)


JPEG2000 display/conversion issues

Describe the bug
Color changes incorrectly when converting images to JPEG2000 format
Expected behavior
The color of the converted image should be the same as the original image
Screenshots
Original image

Converted image opens in xnview

Converted image opens in photoshop

Image converted by other software open in imagetoolbox

Smartphone (please complete the following information):

Device: HONOR DIO-AN00
OS: Magic UI 6.1 / Android 12
ImageToolbox: 2.9.1-beta01-foss (148)

should be fixed now


CameraType = > back,front not working

Issue Description
CameraType => back, front does not make any effect on which camera is opening.
unless i use cameraFlipImage={require('path/to/image')}, when i click on this image only then the camera is switched.
How can i use this Prop CameraType ? Please guide
Steps to Reproduce / Code Snippets / Screenshots
 <Modal animationType="slide" transparent={true} visible={this.state.modalAttendance.modal} onRequestClose={() => this.state.modalAttendance.toggleModal()} >
                    <View style={{ flex: 1 }}>
                        <CameraScreen
                            cameraFlipImage={require('../assets/menu/qr.png')}
                            hideControls={false}
                            cameraType={CameraType.Front}//CameraType.Back
                            // Barcode props
                            scanBarcode={this.state.modalAttendance.scanning}
                            // onReadCode={(event) => Alert.alert('QR code found')} // optional
                            onReadCode={(event) => {
                                let data = event.nativeEvent.codeStringValue
                                if (this.state.modalAttendance.scanning) {
                                    this.setState({ modalAttendance: { ...this.state.modalAttendance, scanning: !this.state.modalAttendance.scanning } }, () => this.onBarCodeRead(data))
                                }
                            }
                            }
                            showFrame={true} // (default false) optional, show frame with transparent layer (qr code or barcode will be read on this area ONLY), start animation for scanner,that stoped when find any code. Frame always at center of the screen
                            laserColor={themeColors.danger2} // (default red) optional, color of laser in scanner frame
                            frameColor={themeColors.warning2} // (default white) optional, color of border of scanner frame
                        />
                    </View>
</Modal>

Environment

"@react-navigation/native": "^6.0.13",
React Native version: 0.70.3
Platform(s) (iOS, Android, or both?): Only tested on 'Android' yet
Device info (Simulator/Device? OS version? Debug/Release?): 'Simulator (PIXEL 5 API 31) debug mode'

Hello,
I have the same issue.
I've tried as in the docs but it doesn't do anything.

@robertcoroianu
I have fixed it by changing some code
node_modules\react-native-camera-kit\dist\CameraScreen.js
cameraType: props.CameraType || CameraType.Front,

COPY PASTE this function in the file
 componentDidUpdate(prevProps, prevState) {
        if (this.state.cameraType != this.props.cameraType && this.props.cameraType) {
            this.setState({ cameraType: this.props.cameraType })
        }
    }

Should be fixed in #545

Still not fixed in the library.
Used the Code from @ahmad6242
works perfectly. Thanks @ahmad6242


[FEATURE REQ] Buffered Upload for Append Blobs

We are migrating blob component from old SDK azure-storage-5.5.0 to new SDK azure-storage-blob-12.10.0.
Old SDK - We used CloudAppendBlob.upload(inputStream, -1) to append blob with -1 length size. We are getting input as stream, so it will be difficult to get exact size of input.
As per Java docs - InputStream.available() can provide estimate size only which is not reliable.
So we are using -1 for stream object with old SDK which is working fine.
New SDK - I tried samething with new SDK to append blob and upload blob but I am getting below UnexpectedLengthException error, please find below details. As per java docs, we need to provide exact length, which is not possible for Stream object, and we can't provide exact length of a Stream object.
I observed same issue in other blob client as well - BlobClient.upload(stream, -1, true);
Can I request you to please provide option to upload blob with unknow size. Please find below details and let me know for any issues.
New SDK Code for Append blob
AppendBlobClient.appendBlock(blobAsInputStream, -1);
Code ScreenShot

Error StackTrace
com.azure.core.exception.UnexpectedLengthException: Request body emitted 71 bytes, more than the expected -1 bytes.
	at com.azure.storage.common.Utility.lambda$convertStreamToByteBuffer$3(Utility.java:292) ~[azure-storage-common-12.10.0.jar:?]
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:243) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.drain(FluxConcatMap.java:359) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.onComplete(FluxConcatMap.java:268) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.Operators.complete(Operators.java:135) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxEmpty.subscribe(FluxEmpty.java:41) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:62) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxDefer.subscribe(FluxDefer.java:54) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.publisher.FluxSubscribeOn$SubscribeOnSubscriber.run(FluxSubscribeOn.java:187) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:84) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:37) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_242]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_242]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_242]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_242]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242]
	Suppressed: java.lang.Exception: #block terminated with an error
		at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
		at reactor.core.publisher.Mono.block(Mono.java:1685) ~[reactor-core-3.3.12.RELEASE.jar:3.3.12.RELEASE]
		at com.azure.storage.common.implementation.StorageImplUtils.blockWithOptionalTimeout(StorageImplUtils.java:131) ~[azure-storage-common-12.10.0.jar:?]
		at com.azure.storage.blob.specialized.AppendBlobClient.appendBlockWithResponse(AppendBlobClient.java:227) ~[azure-storage-blob-12.10.0.jar:?]
		at com.azure.storage.blob.specialized.AppendBlobClient.appendBlock(AppendBlobClient.java:192) ~[azure-storage-blob-12.10.0.jar:?]

Java SDK

Old SDK

Setup (please complete the following information if applicable):
OS: window
IDE : eclipse
Version of the Library used: azure-storage-blob-12.10.0

Hi @abhikt48
Thank you for posting this feature request.
As you can see from the docs, the AppendBlob upload does require that you know the size of the input before hand.
We will discuss this request with the rest of the team and determine if we can take this on as a feature request and appropriately schedule it in our backlog

+1 for this feature.

Two different issues are being brought up here.
BlobClient.upload(stream, -1, true) is being brought upon the side, and the fix for that is far simpler. This has to do with our sync to async conversions and how InputStreams are currently converted. This upgrade is currently being looked into and is tracked under https://github.com/Azure/azure-sdk-for-java/issues/20567.
AppendBlobClient.appendBlock(stream, -1) is an entirely separate issue. While BlobClient is utilizing a buffering strategy to allow for simpler APIs, parallelization, etc., AppendBlobClient, BlockBlobClient, and PageBlobClient do not currently buffer your data. Without buffering data, we cannot determine the data length, which is needed when putting requests on the wire. Accepting a length of -1 here would require significant changes.
Further, the legacy SDK method being mentioned is not even a single append method, but a multi-block append method that (when given -1) would buffer chunks from the InputStream and append them each until the end of the InputStream was reached (this is equivalent to how BlobClient provides helpful functionality on top of BlockBlobClient in this SDK). Without this, the maximum size of InputStream would be the maximum size of an append block (currently 4MB).
Editing this issue title to be a feature request for a buffered upload on AppendBlobClient (and AppendBlobAsyncClient)
@abhikt48 to be clear, the feature we would end up writing to support this scenario would be, in one way or another, a convenience where we loop read 4MB chunks from the InputStream into a buffer and then call appendBlock() for you using the buffered data length as the length argument. You could write a simple version of this to unblock yourself if the functionality is critical.

@abhikt48 hi! did you manage to implement your own version of buffered uploads for the Append client? I'm trying it with a pretty straightforward approach creating chunks of 4MB as follows:
public Flux<AppendBlobItem> appendBlock(String containerName, String blobName, InputStream data) {
	return FluxUtil.toFluxByteBuffer(data, MAX_BYTES_APPEND_BLOCK).flatMap((chunk) -> {
		log.info("Appending chunk of length (in bytes) [{}] to container [{}] and blob [{}]", chunk.limit(), containerName, blobName);
		return this.getAppendBlobAsyncClient(containerName, blobName).appendBlock(Flux.just(chunk), chunk.limit());
	});
}

Where MAX_BYTES_APPEND_BLOCK is the 4MB that appendBlock method allows from the SDK.
The file is uploaded but when I try to download it the data is corrupted. I'm downloading it from the Azure portal UI directly so I don't have a download method written by myself that could be the guilty. I would say there is something going on inside the appendBlock method when sending chunks... This is only happening with the Async client. The same approach is working fine with the Sync client (the sync client receives anInputStream instead of Flux<ByteBuffer> as input).
@jaschrep-msft pinging you as well in case you have any tips to implement this. By the way, if I read from a file into Flux<ByteBuffer>, create chunks of 4MB and write to a local file, the file is not corrupted. That's why I think the way I'm creating the chunks is correct and there might be something corrupting the data when using appendBlock.
This is the local example:
DataInputStream reader = new DataInputStream(new FileInputStream("myfile.pptx"));
var fluxByteBuffer = FluxUtil.toFluxByteBuffer(reader, 4000000); // 4MB
FluxUtil.writeFile(fluxByteBuffer, AsynchronousFileChannel.open(Path.of("myfile_v2.pptx"), StandardOpenOption.CREATE_NEW, StandardOpenOption.WRITE)).subscribe();

@glammers1 Sorry for the delay in response. FluxUtil.writeFile() has reactive code to guarantee no concurrent writes. You code does not have that guarantee in place. You could be getting into a race condition and can confirm this by observing the corrupted data to look for blocks of the observed size being out of order.
If that is not the nature of your corruption, please open a separate bug report rather than continuing on this feature request.

@abhikt48 hi! did you manage to implement your own version of buffered uploads for the Append client? I'm trying it with a pretty straightforward approach creating chunks of 4MB as follows:
public Flux<AppendBlobItem> appendBlock(String containerName, String blobName, InputStream data) {
	return FluxUtil.toFluxByteBuffer(data, MAX_BYTES_APPEND_BLOCK).flatMap((chunk) -> {
		log.info("Appending chunk of length (in bytes) [{}] to container [{}] and blob [{}]", chunk.limit(), containerName, blobName);
		return this.getAppendBlobAsyncClient(containerName, blobName).appendBlock(Flux.just(chunk), chunk.limit());
	});
}

Where MAX_BYTES_APPEND_BLOCK is the 4MB that appendBlock method allows from the SDK.
The file is uploaded but when I try to download it the data is corrupted. I'm downloading it from the Azure portal UI directly so I don't have a download method written by myself that could be the guilty. I would say there is something going on inside the appendBlock method when sending chunks... This is only happening with the Async client. The same approach is working fine with the Sync client (the sync client receives anInputStream instead of Flux<ByteBuffer> as input).
@jaschrep-msft pinging you as well in case you have any tips to implement this. By the way, if I read from a file into Flux<ByteBuffer>, create chunks of 4MB and write to a local file, the file is not corrupted. That's why I think the way I'm creating the chunks is correct and there might be something corrupting the data when using appendBlock.
This is the local example:
DataInputStream reader = new DataInputStream(new FileInputStream("myfile.pptx"));
var fluxByteBuffer = FluxUtil.toFluxByteBuffer(reader, 4000000); // 4MB
FluxUtil.writeFile(fluxByteBuffer, AsynchronousFileChannel.open(Path.of("myfile_v2.pptx"), StandardOpenOption.CREATE_NEW, StandardOpenOption.WRITE)).subscribe();

I'm using files of 10MB for my tests.

I found the issue with my code above some time ago but wanting to write down here what was happening. It has nothing to do with the appendBlock call but with the usage of flatMap.
The flatMap operation in Flux does not guarantee any specific order of processing for the elements. I changed it to concatMap which preserves the order. With that change, the data is not getting corrupted anymore.


Add explicitly support to .NET 6, .NET 7 and .NET 8

This PR aims to solve #183

:white_check_mark: Build VTEX-SDK-dotnet 2.3.462 completed (commit https://github.com/guibranco/VTEX-SDK-dotnet/commit/a07ed8647b by @guibranco)


(How) do triggers work?

The follwing file shows a collection of 10 examples that @kyoDralliam and I don't understand about triggers. I'm not sure if they are bugs.
module Test

assume val p: int -> prop
assume val q: int -> prop

/// First part: weird errors in requires
/// ====================================

/// 1. What is this error? Is the location wrong? It says ‘assertion failed’ on ‘p x’
// let p_1 () : Lemma (requires (forall x . {:pattern q x} p x))
//                    (ensures (q 0 ==> p 0)) =
//  ()

/// 2. Here's a copy of that same error:
// let p_2 () : Lemma (requires (forall x . {:pattern q x} p x /\ q x)) =
//   admit ()

/// 3. Why does removing the trigger remove the error?
// This is disabled because leaving it breaks the rest of the file
// let p_3 () : Lemma (requires (forall x . p x /\ q x)) =
//   admit ()

/// 4. But the admit is needed ?!
// let p_4 () : Lemma (requires (forall x . p x /\ q x)) = ()

/// 5. Here's another trick to solve the error without removing the trigger (adding an assert) (This one doesn't work in batch mode?!)
// let p_5 () : Lemma (requires (forall x . {:pattern q x} (p x /\ q x))) =
//   assert ((q 0 /\ p 0) ==> (p 0 /\ q 0));
//   admit ()

/// 6. Spot the difference! This one fails
// let p_6 () : Lemma (requires (forall x . {:pattern q x} (p x /\ q x))) =
//   assert ((p 0 /\ q 0) ==> (p 0 /\ q 0));
//   admit ()

/// 7. We thought this might be due to ‘prop’, but it fails with ‘Type0’ too:

// assume val p': int -> Type0
// assume val q': int -> Type0

// let p_7 () : Lemma (requires (forall x . {:pattern q' x} (p' x /\ q' x)))
//                     (ensures True) =
//   admit ()

/// 8. Here's a comparison with Dafny:

// let p_8 () : Lemma (requires (forall x . {:pattern q x} p x /\ q x))
//                    (ensures (q 0 ==> p 0)) =
//  assert (q 0 ==> p 0)

// This works in Dafny
// predicate P(i: int)
// predicate Q(i: int)
//
// lemma P_0 ()
//   requires (forall x: int {:trigger Q(x)} :: P(x))
//   ensures (Q(0) ==> P(0)) {
// }

/// 9. This failure is expected (there's nothing to trigger on)
// let p_9 () : Lemma (requires (forall x . {:pattern q x} p x /\ q x))
//                    (ensures (p 0)) =
//  ()

/// 10. But then why does this work?
// let p_10 () : Lemma (p 0) =
//  assume (forall x . {:pattern q x} p x /\ q x);
//  ()

/// 11. Using SMT axioms works exactly as expected:

assume P_AND_Q : (forall x . {:pattern q x} p x /\ q x)

// This fails as expected (no trigger)
// let p_11 () : Lemma (p 0) =
//  ()

// This succeeds as expected
// let p_12 () : Lemma (p 0) =
//  assert (q 0 == q 0);
//  ()

CC @nikswamy

A lot of what seems to be going wrong here is due to bugs in desugaring, rather than anything to do with triggers.
Notably, Lemma (requires p) is actually treated as Lemma p which is treated as ... Lemma (ensures p). :P
There also seem to be discrepancies between the way val p : .. -> Lemma ... is handled vs. let p .. : Lemma = e is handled.  If you switch to writing val and let separately then I think the strange behavior you observed  goes away.
So, how about this for a plan:

I will work on fixing the desugaring issues for Lemma (requires p) instead desugaring it to Lemma (requires p) (ensures True) which is your intention, I think. (easy)

I will investigate why we get different SMT queries for val+let vs an annotated let only. These discrepancies seem to be a recurring issue ...

Meanwhile, it would be great if you could try out your examples using val + let and without using Lemma (requires p). I'll be curious to know if you still have unexplained behavior.

FYI, looking at the desugaring code for Lemma, I think it makes more sense to forbid questionable uses of the Lemma sugar. So, Lemma (requires p) will be forbidden. Are you okay with that?
             let expected_one_of = ["Lemma post";
                                    "Lemma (ensures post)";
                                    "Lemma (requires pre) (ensures post)";
                                    "Lemma (ensures post) [SMTPat ...]";
                                    "Lemma (ensures post) (decreases d)";
                                    "Lemma (ensures post) (decreases d) [SMTPat ...]";
                                    "Lemma (requires pre) (ensures post) (decreases d)";
                                    "Lemma (requires pre) (ensures post) [SMTPat ...]";
                                    "Lemma (requires pre) (ensures post) (decreases d) [SMTPat ...]"] in
             let msg = String.concat "\n\t" expected_one_of in
             raise (Error("Invalid combination of arguments to 'Lemma'; expected one of\n\t" ^ msg, t.range))

As for my point (2), it seems that the problem is partly described by my commit above https://github.com/FStarLang/FStar/commit/3520036bbc11b79ce174edcb2280c3affcdadc54
Take the first example : When checking
Lemma (requires (forall x . {:pattern q x} p x))
             (ensures (q 0 ==> p 0))
<:
Lemma (requires (forall x . {:pattern q x} p x))
             (ensures (q 0 ==> p 0))

We were correctly generating the SMT query:
forall (uu___156851:Prims.unit).
  (*could not prove post-condition*)
  forall (p:Prims.pure_post Prims.unit).
    (forall (x:Prims.int). {:pattern  Issue1208.q x } Issue1208.p x) /\
    (forall (x:Prims.unit). Issue1208.q 0 ==> Issue1208.p 0 ==> p x) ==>
    (forall (y:Prims.unit). y == () ==> p y) /\
(** THIS NEXT BIT IS THE INTERESTING YET REDUNDANT PART **)
(*could not prove post-condition*)
  forall (p:Prims.pure_post Prims.unit).
    (forall (x:Prims.int). {:pattern  Issue1208.q x } Issue1208.p x) /\
    (forall (x:Prims.unit). Issue1208.q 0 ==> Issue1208.p 0 ==> p x) ==>
    (forall (x:Prims.int). {:pattern  Issue1208.q x } Issue1208.p x (* <-- THIS PART *) ) /\
    (forall (x:Prims.unit). Issue1208.q 0 ==> Issue1208.p 0 ==> p x)

Now, notice that second part of that VC is indeed not provable precisely because the trigger provided in the :pattern annotation is makes it impossible to prove THIS PART of the formula.
I've now removed this redundant check as described in the commit message.
This will hopefully reduce the surprise factor in examples such as the one you report.
And also reduce some of the redundancy in the VCs that we're generating.

Thanks. It makes a sense. Question though:
In the first part, how does z3 succeed?
forall (uu___156851:Prims.unit).
  (*could not prove post-condition*)
  forall (p:Prims.pure_post Prims.unit).
    (forall (x:Prims.int). {:pattern  Issue1208.q x } Issue1208.p x) /\
    (forall (x:Prims.unit). Issue1208.q 0 ==> Issue1208.p 0 ==> p x) ==>
    (forall (y:Prims.unit). y == () ==> p y) /\

I'd expect it to not  get an instance of Issue1208.q 0 until it instantiates the second quantifier, which shouldn't really happen, since there's nothing to trigger on.

FYI, looking at the desugaring code for Lemma, I think it makes more sense to forbid questionable uses of the Lemma sugar. So, Lemma (requires p) will be forbidden. Are you okay with that?

That sounds OK; hopefully the error message can give guidance about adding the missing elements (it feels a bit counterintuitive to allow some keywords on their own, but not all).  WOuld it be tricky to support requires alone as well?

Trying with vals and proper Lemma annotations works much better :)
I have only two issues left:
assume P_AND_Q : (forall x . {:pattern q x} p x /\ q x)

// This works as expected
let p_12 () : Lemma (p 0) =
 assert (q 0 == q 0);
 ()

// Why does this fail?
val p_13 : unit -> Lemma (p 0)
let p_13 () =
 assert (q 0 == q 0);
 ()

// Why does this work? There's nothing to trigger on, is there?
val p_10 : unit -> Lemma (requires True) (ensures p 0)
let p_10 () =
 assume (forall x . {:pattern q x} p x /\ q x);
 ()

Regarding this part

In the first part, how does z3 succeed?
forall (uu___156851:Prims.unit).
(could not prove post-condition)
forall (p:Prims.pure_post Prims.unit).
(forall (x:Prims.int). {:pattern  Issue1208.q x } Issue1208.p x) /
(** THIS QUANTIFIER **) (forall (x:Prims.unit). Issue1208.q 0 ==> Issue1208.p 0 ==> p x) ==>
(forall (y:Prims.unit). y == () ==> p y) /
I'd expect it to not get an instance of Issue1208.q 0 until it instantiates the second quantifier, which
shouldn't really happen, since there's nothing to trigger on.

The lack of explicit pattern on a quantifier should not be interpreted as "nothing to trigger on". Instead, it means that Z3+F*'s SMT encoding is free to choose a trigger as it sees fit.
In this particular case, F* chooses the pattern on the THIS QUANTIFIER to be p x. In other cases, F* will not choose a pattern and let Z3's trigger selection do the job.

About this one:
assume P_AND_Q : (forall x . {:pattern q x} p x /\ q x)

// This works as expected
let p_12 () : Lemma (p 0) =
 assert (q 0 == q 0);
 ()

// Why does this fail?
val p_13 : unit -> Lemma (p 0)
let p_13 () =
 assert (q 0 == q 0);
 ()

This is because in the second example q 0 == q 0 happens to be simplified away to True by F* before SMT encoding. For obscure reasons (in particular, additional monadic binds that get inserted along the way), in the first example, this simplification doesn't take place and q 0 is still left in the SMT query.

Finally, this one is quite interesting. Heads up @mtzguido and @Chris-Hawblitzel (who noticed this issue in another context). Would be useful to get your feedback on this.
// Why does this work? There's nothing to trigger on, is there?
val p_10 : unit -> Lemma (requires True) (ensures p 0)
let p_10 () =
 assume (forall x . {:pattern q x} p x /\ q x);
 ()

What's happening here is that the assume (forall x. ...) shows up in the SMT encoding in two forms:

As a Z3 forall, correctly guarded by the pattern. (this is fine)

But, we also encode the assume (forall x. ...) as a term in Z3 of the form (Prims._assume (Prims.l_Forall Prims.int Tm_abs_xxx)), which is the underlying encoding of the forall term in F*.

This leads to a problem when combined with some work we did this past summer. With @mtzguido, we added the following assertion to the background axioms in F*'s Z3 encoding.
;;;;;;;;;;;;;;;;forall interpretation
;;; Fact-ids: Name Prims.l_Forall; Namespace Prims
(assert (! (forall ((@x0 Term) (@x1 Term))
                   (! (iff (forall ((@x2 Term))
                                   (! (implies (HasTypeZ @x2
                                                         @x0)
                                               (Valid (ApplyTT @x1
                                                               @x2)))

                                      :pattern ((HasTypeZ @x2
                                                          @x0))
                                      :qid forall-interp.1))
                           (Valid (Prims.l_Forall @x0
                                                  @x1)))

                      :pattern ((Prims.l_Forall @x0
                                                @x1))
                      :qid forall-interp))
           :named forall-interp))

This axiom interprets the l_Forall as a Z3 (forall ... ), but, in doing so, it drops the pattern on the quantifier that was present in the source program.
So, now the Z3 instantiates the quantifier as it pleases and is able to prove the post-condition.

I'm inclined to remove this forall-interp and its counterpart exists-interp from the background axioms, since they lead to this kind of unpredictable behavior.
WDYT?
;;;;;;;;;;;;;;;;exists interpretation
;;; Fact-ids: Name Prims.l_Exists; Namespace Prims
(assert (! (forall ((@x0 Term) (@x1 Term))
                   (! (iff (exists ((@x2 Term))
                                   (! (implies (HasTypeZ @x2
                                                         @x0)
                                               (Valid (ApplyTT @x1
                                                               @x2)))

                                      :pattern ((HasTypeZ @x2
                                                          @x0))
                                      :qid exists-interp.1))
                           (Valid (Prims.l_Exists @x0
                                                  @x1)))

                      :pattern ((Prims.l_Exists @x0
                                                @x1))
                      :qid exists-interp))
           :named exists-interp))```

The lack of explicit pattern on a quantifier should not be interpreted as "nothing to trigger on". Instead, it means that Z3+F*'s SMT encoding is free to choose a trigger as it sees fit.

Yes, of course; but where does the instance of p (the VC p taking a unit come from?)

This is because in the second example q 0 == q 0 happens to be simplified away to True by F* before SMT encoding. For obscure reasons (in particular, additional monadic binds that get inserted along the way), in the first example, this simplification doesn't take place and q 0 is still left in the SMT query.

Fascinating, thanks!

I'm inclined to remove this forall-interp and its counterpart exists-interp from the background axioms, since they lead to this kind of unpredictable behavior.

Does that break anything? O:)

The lack of explicit pattern on a quantifier should not be interpreted as "nothing to trigger on". Instead,
it means that Z3+F*'s SMT encoding is free to choose a trigger as it sees fit.

Yes, of course; but where does the instance of p (the VC p taking a unit come from?)

The last forall is in positive position (and the whole formula is negated for the SMT solver), so it gets skolemized, producing a p y.

I'm inclined to remove this forall-interp and its counterpart exists-interp from the background axioms,
since they lead to this kind of unpredictable behavior.

Does that break anything? O:)

It was added recently to enable some kinds of proofs that were showing up as we were working on tactics. I forget the examples that really needed them, though. Certainly the bulk of our examples do not need this axiom. Guido may recall the specifics better than I do.
In any case, removing this axiom will only require more explicit proofs occasionally, which I find preferable to introducing unpredictability more commonly.
  But when the pattern gets dropped, there's a matching loop (using --z3cliopt smt.QI.EAGER_THRESHOLD=10000 makes the matching loop noticeable, and causes Z3 to take a long time).

I think the interpretation of l_Forall and l_Exists has been in place for quite a long time. For tactics we just made a slight change to the trigger, turning it from Valid (l_Forall t p) to l_Forall t p, which is partially the cause for this last example (i.e., changing it back causes p_10 to fail).
That change wasn't strictly related to tactics, or not anymore at least. We had the problem that unfolding logical connectives would change the encoding and make certain queries fail, but we worked around that in tactics by preventing the unfolding instead of trying to make the unfolded queries succeed.
Removing the interpretations altogether causes many failures (~70) across the regression suite. Changing the trigger back to the way it was has some impact but it seems much smaller (still running it).

Thanks Guido ... it's coming back now.
Where are those ~70 failures coming from? If it's just in core libraries like FStar.Squash and FStar.Classical etc., perhaps we can revise them to make use of this axiom more explicitly.
I also wonder if we should revise the encoding so that rather than a global axiom for l_Forall and l_Exists (for which I don't see a way to encode the user's triggers), we emit axioms on a per-occurrence basis while preserving the triggering behavior requested by the user.

FYI, @chris-hawblitzel's example of a matching loop via forall_interp is now partially solved (or at least side-stepped). We no longer emit equalities in the VC among unit-typed terms.
This makes Chris' program fail very quickly, as was the intention.
 This invocation still takes ages.
$ fstar --z3cliopt smt.QI.EAGER_THRESHOLD=10000  test.fst

FYI, the relevant commits that remove equalities on unit-typed terms are
4030ed84f718e7116caafec818e56913cd9920b4
and
254ce7a2c5e4d6ea01b5a63398fae3790babb202

The generic forall-interp and exists-interp are now gone, in favor of specific instantiations produced on an as-needed basis by the encoding.
Take this program:
module Bug1208
assume val f : int -> int
assume val s : int -> int

let q =
  let _ = () in
  (forall i.{:pattern (f (s i))} f i <= f (s i))

let l () : Lemma (f 0 <= f (s (s 0)))
 =
 assume q;
 assert (f (s 0) <= f 0) // should fail quickly

It fails quickly in F* master, e.g., version 885a773b94b063325aca4f371e34bfd959bb1357
Although, before this change, say, with version, 68161f469a5f3b32184bed665134b0f665227d36, this enters a matching loop in Z3.
fstar bug1208.fst --z3cliopt smt.qi.eager_threshold=10000 --max_fuel 0 --max_ifuel 0 doesn't return for a long while (i had to kill it).


ApplySchema currently fails for some sql commands

In general application owners may want to write the DDL scripts in the following manner:
drop table if exists shipment;
create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid));
...
...
However if the table shipment doesn;t exist initially the command drop table if exists shipment; should gracefully execute and after that create the shipment table, but when we try to execute the above two commands when the table shipment doesn;t exists, it gives the following error:
E0526 09:22:49.821551    6785 main.go:43] Remote error: rpc error: code = 13 desc = invalid header field value "Schema change failed, ExecuteResult: {\n  "FailedShards": null,\n  "SuccessShards": null,\n  "CurSQLIndex": 0,\n  "Sqls": [\n    "drop table if exists shipment",\n    "create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid))",\n    "create table runsheet (runsheetid bigint(20) not null, createdatetime datetime default current_timestamp, isactive tinyint(1) not null default 1, deliverydate datetime default null, primary key (runsheetid))",\n    "create table runsheet_shipments(runsheetid bigint(20), shipmentid bigint(20), primary key(runsheetid, shipmentid))",\n    "create table shipment_address (shipmentid bigint(20) not null, addressid bigint(20) not null, primary key(shipmentid, addressid))",\n    "create table dummy (shipmentid varchar(20), trackingid varchar(15) default null, createdatetime datetime default current_timestamp, primary key (shipmentid))",\n    "create table shipment_status(shipmentid bigint(20) not null, updatedatetime datetime default current_timestamp, status tinyint(1))"\n  ],\n  "ExecutorErr": "Schema change: 'drop table if exists shipment' does not introduce any table definition change.",\n  "TotalTimeSpent": 45414411\n}\n"
Ideally it should gracefully handle the drop table if not exists and create the table.

I verified that this has some problems when drop and creation of the table happens in the same script, if i try to run a script with the following commands:
drop table if exists shipment;
drop table if exists runsheet;
drop table if exists runsheet_shipments;
drop table if exists shipment_address;
drop table if exists shipment_status;
drop table if exists dummy;
It works great.
This seems to be a valid script:
drop table if exists shipment;
create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid));
drop table if exists runsheet;
create table runsheet (runsheetid bigint(20) not null, createdatetime datetime default current_timestamp, isactive tinyint(1) not null default 1, deliverydate datetime default null, primary key (runsheetid));
drop table if exists runsheet_shipments;
create table runsheet_shipments(runsheetid bigint(20), shipmentid bigint(20), primary key(runsheetid, shipmentid));
drop table if exists shipment_address;
create table shipment_address (shipmentid bigint(20) not null, addressid bigint(20) not null, primary key(shipmentid, addressid));
drop table if exists dummy;
create table dummy (shipmentid varchar(20), trackingid varchar(15) default null, createdatetime datetime default current_timestamp, primary key (shipmentid));
drop table if exists shipment_status;
create table shipment_status(shipmentid bigint(20) not null, updatedatetime datetime default current_timestamp, status tinyint(1));
but couldn;t be executed using ApplySchema, it gives the following exception:
E0526 09:36:31.120971   13538 main.go:43] Remote error: rpc error: code = 13 desc = invalid header field value "Schema change failed, ExecuteResult: {\n  "FailedShards": null,\n  "SuccessShards": null,\n  "CurSQLIndex": 0,\n  "Sqls": [\n    "drop table if exists shipment",\n    "create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid))",\n    "drop table if exists runsheet",\n    "create table runsheet (runsheetid bigint(20) not null, createdatetime datetime default current_timestamp, isactive tinyint(1) not null default 1, deliverydate datetime default null, primary key (runsheetid))",\n    "drop table if exists runsheet_shipments",\n    "create table runsheet_shipments(runsheetid bigint(20), shipmentid bigint(20), primary key(runsheetid, shipmentid))",\n    "drop table if exists shipment_address",\n    "create table shipment_address (shipmentid bigint(20) not null, addressid bigint(20) not null, primary key(shipmentid, addressid))",\n    "drop table if exists dummy",\n    "create table dummy (shipmentid varchar(20), trackingid varchar(15) default null, createdatetime datetime default current_timestamp, primary key (shipmentid))",\n    "drop table if exists shipment_status",\n    "create table shipment_status(shipmentid bigint(20) not null, updatedatetime datetime default current_timestamp, status tinyint(1))"\n  ],\n  "ExecutorErr": "rpc error: code = 13 desc = invalid header field value \"TabletManager.PreflightSchema on test-0000000200 error: /usr/bin/mysql: ERROR 1050 (42S01) at line 3: Table 'shipment' already exists\\n\"",\n  "TotalTimeSpent": 206411085\n}\n"

You're seeing the error:

Schema change: 'drop table if exists shipment' does not introduce any table definition change.

It comes from here:
https://github.com/youtube/vitess/blob/master/go/vt/schemamanager/tablet_executor.go#L170
ApplySchema runs every query on a temporary database first (preflight mode) and checks if it actually results into a change of the schema. Since the table didn't exist in the first place, the "drop table if exists" query didn't have any impact.
The solution is to exclude such queries from the check in tablet_executor.go. An ideal solution would use the SQL parser to check if it's a "drop table if exists" statement. As a quick hack, you could also do a string comparison to exclude it.
I won't have time to work on this in the next days. Let me know if you're interested on fixing it.

Sure, I can take it up, will get into the details and come back in case i have any concerns.

I think there is more to this then if the schema doesn;t introduce any table definition change.
I considered a second scenario in which my tables actually exists in the shards and then execute these queries, which introduce a table definition change in every statement.
drop table if exists shipment;
create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid));
drop table if exists runsheet;
create table runsheet (runsheetid bigint(20) not null, createdatetime datetime default current_timestamp, isactive tinyint(1) not null default 1, deliverydate datetime default null, primary key (runsheetid));
drop table if exists runsheet_shipments;
create table runsheet_shipments(runsheetid bigint(20), shipmentid bigint(20), primary key(runsheetid, shipmentid));
drop table if exists shipment_address;
create table shipment_address (shipmentid bigint(20) not null, addressid bigint(20) not null, primary key(shipmentid, addressid));
drop table if exists dummy;
create table dummy (shipmentid varchar(20), trackingid varchar(15) default null, createdatetime datetime default current_timestamp, primary key (shipmentid));
drop table if exists shipment_status;
create table shipment_status(shipmentid bigint(20) not null, updatedatetime datetime default current_timestamp, status tinyint(1));
"ExecutorErr": "rpc error: code = 13 desc = invalid header field value \"TabletManager.PreflightSchema on test-0000000200 error: /usr/bin/mysql: ERROR 1050 (42S01) at line 3: Table 'shipment' already exists
Just want to checkout are these queries executed concurrently or serially?

Attaching the Vitess Components logs for the reference, this time i tried executing the following queries:
drop table if exists shipment;
drop table if exists runsheet;
drop table if exists runsheet_shipments;
drop table if exists dummy;
drop table if exists shipment_status;
drop table if exists shipment_address;
create table shipment (shipmentid bigint(20) not null, trackingid varchar(15) default null, createdatetime datetime default current_timestamp,isactive tinyint(1) not null default 0, primary key (shipmentid));
create table runsheet (runsheetid bigint(20) not null, createdatetime datetime default current_timestamp, isactive tinyint(1) not null default 1, deliverydate datetime default null, primary key (runsheetid));
create table runsheet_shipments(runsheetid bigint(20), shipmentid bigint(20), primary key(runsheetid, shipmentid));
create table shipment_address (shipmentid bigint(20) not null, addressid bigint(20) not null, primary key(shipmentid, addressid));
create table dummy (shipmentid varchar(20), trackingid varchar(15) default null, createdatetime datetime default current_timestamp, primary key (shipmentid));
create table shipment_status(shipmentid bigint(20) not null, updatedatetime datetime default current_timestamp, status tinyint(1));
Also validated that before executing these queries all the 6 tables were existing in both the shards.
VitessLogs.txt

@michael-berlin @sougou
On checking the code flow, i found that each sql statement from the script specified in the ApplySchema command are applied individually to the BaseSchema and not sequentially in the way its being specified in the script. Is there any reason for applying the statements one at a time only to the BaseSchema rather than applying it sequentially on the Base Schema?
I am referring to this code in tablet_executor.go
func (exec *TabletExecutor) preflightSchemaChanges(ctx context.Context, sqls []string) error { 	exec.schemaDiffs = make([]*tmutils.SchemaChangeResult, len(sqls)) 	_for i := range sqls { 		schemaDiff, err := exec.tmClient.PreflightSchema( 			ctx, exec.tablets[0], sqls[i]) 		if err != nil { 			fmt.Println(err) 			return err 		}_ 		exec.schemaDiffs[i] = schemaDiff 		diffs := tmutils.DiffSchemaToArray( 			"BeforeSchema", 			exec.schemaDiffs[i].BeforeSchema, 			"AfterSchema", 			exec.schemaDiffs[i].AfterSchema) 		if len(diffs) == 0 { 			return fmt.Errorf("Schema change: '%s' does not introduce any table definition change.", sqls[i]) 		} 	} 	return nil }

So as a part of this fix, i think that all the statements given in the script should be combined and executed sequentially in one go.

I agree as far as the preflight is concerned. I'm working on this right now and will publish a pull request for it later.

me wrote:

I agree as far as the preflight is concerned. I'm working on this right now and will publish a pull request for it later.

Fix and e2e test here: https://github.com/youtube/vitess/pull/1749


add domain for Chulalongkorn University

@peyrone I am sorry, the domain chula.ac.th is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Pack at https://education.github.com/discount_requests/application. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


Eco discharge mode

After changing inventer mode to Eco discharge mode is created / enabled timer with predefined power of 0% ... That is bug. Discharging at 0% of power of inventer means discharging at 0W ... and that means do nothing.
It is needed to setup this timer with power of 100% or with already user predefined value like 70%
For discharge limit cannot be used or setted value sensor.batter_discharge_limit ... because it is in Ampers and it is readonly value from BMS that show what is the maximum power of discharging. So limit of discharge in Eco discharge mode is absolutely independent on this, because it it percent of power of inventer (for example 10KW inventer has 100% as 10KW and it did not say nothing about ampers of discharging, because you need to know the battery voltage.

This is not a bug - you need to specify what power you want to use for discharging via a service. Not everybody wants to charge with 100% or any other predefined value. The inverter unfortunately tends to forget what the last value was so it is best to simply set this value whenever setting Eco modes in a sequence or using script - for example:
    sequence:       - device_id: ID_of_inverter         domain: select         entity_id: select.inverter_operation_mode         type: select_option         option: Eco charge mode       - device_id: ID_of_inverter         domain: number         entity_id: number.eco_mode_power         type: set_value         value: XY

it it percent of power of inventer (for example 10KW inventer has 100% as 10KW and it did not say nothing about ampers of discharging, because you need to know the battery voltage

The inverter will take care of this and if maximum battery current reported by BMS  is lower than the power set in the operation mode it will reduce it. Always the lower value of the two will be used.

Yes, you are right.
Sorry and thanks. Solved... It's a shame there isn't a proper manual


Gitlab docker tag is remove

It looks like the docker tag is remove from the runner.

https://docs.gitlab.com/ee/update/deprecations.html#removal-of-tags-from-small-saas-runners-on-linux

Looks like we could remove the docker and python tags from gitlab CI config? https://about.gitlab.com/blog/2023/08/15/removing-tags-from-small-saas-runner-on-linux/#how-to-avoid-jobs-getting-stuck
Does someone know the difference between changing them to saas-linux-small-amd64 vs removing them? Not clear to me...

Removing them solved the issue for me but couldn't find the answer on your question either.

Ok, so remove and see how it goes? If someone reports any issues, we can look at that...


iPad rotation bug

Hi
I had been fighting with this plugin bug for the past few days on ipad.
I have a list which expected to split to 2 columns in landscape and back to 1 column in portrait. But the result is that it will on every alternative change from portrait to landscape show only one column instead of 2.
I still can't find out why every alternative change from portrait to landscape. But I can see that you only remove the hidden column on the next visit to the refill() function and on the instance that show 1 column in landscape, desktop browser tend to fire refill() twice which will cover the incapability to render properly of the list in the first call of refill(). This however is not same situation for iPad. refill() only fire once and by the time refill() is able remove the hidden column it is already too late because all the items already got into the first column.
Long story short, eventually I came up with this solution which will solve my problem and possibly other people's:
At the first line of the ensureColumns() function, I will use the following line instead of the orginal one.
var createdCnt = this.columns.filter(':visible').length;
This is to filter out those are not viewable (anyway) and count those visible, before the unused column really get deleted.
Hop this can help
D.

Thanks you legend!


CUDA_ERROR_OUT_OF_MEMORY tensorflow 1.4

System information
OS - High Sierra 10.13
Tensorflow - 1.4
Keras - 2.0.9
CUDA - 9
cuDNN - 7
Describe the problem
CUDA_ERROR_OUT_OF_MEMORY running tensorflow on GPU
Simple program:
import tensorflow as tf
with tf.device('/gpu:0'):
    a = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[2, 3], name='a')
    b = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[3, 2], name='b')
    c = tf.matmul(a, b)

with tf.Session() as sess:
    print (sess.run(c))

Output:
(tensorflow) Smit-Shilu:Desktop smitshilu$ python gputest.py
2017-11-07 08:55:50.690390: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:856] OS X does not support NUMA - returning NUMA node zero
2017-11-07 08:55:50.690536: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1031] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.6705
pciBusID: 0000:c3:00.0
totalMemory: 11.00GiB freeMemory: 10.81GiB
2017-11-07 08:55:50.690560: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1121] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:c3:00.0, compute capability: 6.1)
2017-11-07 08:55:50.690914: E tensorflow/stream_executor/cuda/cuda_driver.cc:936] failed to allocate 10.27G<PHONE_NUMBER>4 bytes) from device: CUDA_ERROR_OUT_OF_MEMORY
2017-11-07 08:55:50.691022: E tensorflow/stream_executor/cuda/cuda_driver.cc:936] failed to allocate 9.24G<PHONE_NUMBER> bytes) from device: CUDA_ERROR_OUT_OF_MEMORY
[[ 22.  28.]
 [ 49.  64.]]

CUDA_ERROR_OUT_OF_MEMORY when import Keras after upgrading to 10.13 and 1.4
>>> from keras.callbacks import *
Using TensorFlow backend.
2017-11-06 16:30:54.704584: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:856] OS X does not support NUMA - returning NUMA node zero
2017-11-06 16:30:54.704700: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1031] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.6705
pciBusID: 0000:c3:00.0
totalMemory: 11.00GiB freeMemory: 10.81GiB
2017-11-06 16:30:54.704725: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1121] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:c3:00.0, compute capability: 6.1)
2017-11-06 16:30:54.705019: E tensorflow/stream_executor/cuda/cuda_driver.cc:936] failed to allocate 10.27G<PHONE_NUMBER>4 bytes) from device: CUDA_ERROR_OUT_OF_MEMORY
2017-11-06 16:30:54.705125: E tensorflow/stream_executor/cuda/cuda_driver.cc:936] failed to allocate 9.24G<PHONE_NUMBER> bytes) from device: CUDA_ERROR_OUT_OF_MEMORY

This seems to be a duplicate of #14107.
For questions related to reducing memory usage for your specific case, please ask a question on StackOverflow, which we also monitor. Thanks!

@angersson I am not sure whether it is duplicate or not. But I couldn't find a solution for this. The problem wasn't there for 1.2

#14107 discusses 1.4's extra GPU memory usage compared to older versions, which seems to be the same issue that you're facing.
For help with making adjustments for your specific case, Stack Overflow is our preferred location to ask questions. Thanks!

I have the same problem, how do you fix it.  The out of memory error also occurs in pytorch when you allocate memory more than 8gb or so


Daheimladen: Document Firmware requirement

Ok, I will trust the experienced
@utsavanand2  pls change the firmware
Originally posted by @VolkerK62 in https://github.com/evcc-io/evcc/discussions/2784#discussioncomment-2323927

Thanks a lot @andig for the issue documenting the requirement :)

Done as part of the template


More accurate typing of Object.assign and React component setState()

This is a proposal for solving the second use case mentioned in Issue #6218
Problem

/**
 * This class is a given by the React framework
 */
class ReactComponent<S> {
    protected _state: S;

    /**
     * This method actually accepts any supertype of S
     */
    protected setState(newState: S): void {
        for (let name in newState) {
            if (newState.hasOwnProperty(name)) {
                this._state[name] = newState[name];
            }
        }
    }

    protected componentWillMount(): void {
        // abstract
    }
}

/**
 * Some state interface declaration. Note all members are optional to allow setState to
 * be called with supertypes of BaseState
 */
interface BaseState {
    a?: string;
}

/**
 * My own base class for certain React widgets
 */
class BaseWidget<S extends BaseState> extends ReactComponent<S> {

    constructor() {
        super();
        this._state = {};
    }

    protected componentWillMount(): void {
        this.setState({ a: "boo" });
    }
}

$ tsc v1.ts
v1.ts(39,9): error TS2322: Type '{}' is not assignable to type 'S'.
v1.ts(43,23): error TS2345: Argument of type '{ a: string; }' is not assignable to parameter of type 'S'.

The compiler cannot know that the setState() method will accept any super-type of S, i.e. an object with any subset of the members of S.
Proposal
Add a keyword to type setState() properly.  To avoid confusion, I chose partof instead of e.g. 'supertype of' (see also initial confusion in #6218). For me, 'partof' conveys that I can give the method any object with a subset of the members of S.
/**
 * This class is a given by the React framework
 */
class ReactComponent<S extends {}> {
    protected _state: S;

    /**
     * This method accepts any supertype of S
     */
    protected setState(newState: partof S): void {
    }
}

Properties of partof

Only works for object types (hence the 'extends {}' above) because I wouldn't know how to pass part of e.g. a string
Allows any supertype of the given type
Incorporates knowledge of the generic parameter. Given the class declaration class ReactComponent<S extends { foo: number; }>, one is able to call setState({ foo: 3}) and setState({})  but not setState({ bar: 3 }) inside the class definition.

Comments more than welcome, I'm not a compiler expert. This is just to get the discussion going. If you think there already exists a way of typing this, please check with the original issue for a couple of failed examples.

@RyanCavanaugh what do you think?

Let's say for a moment we had a type operator optionalize that took an object type and produced a new object type whose properties were all optional. What would the trade-offs of that be vs partof for solving the React setState problem?

I think that your description is more concise and clear, and I think optionalize is a very intuitively clear keyword. At first glance, I see no difference in usability between our proposals, do you?

A more general purpose alternative would be to allow super constrains for type parameters:
class ReactComponent<S extends {}> {
    protected _state: S;

    /**
     * This method accepts any supertype of S
     */
    protected setState<T super S>(newState: T): void {
    }
}

The requirement implied by T super S is that T must be a type to which S is assignable.

@ahejlsberg that would work too, but I would avoid the word 'super' because one would not know whether you mean supertype or superclass or super-something-else. Maybe use 'S assignable T'?
However I've found a number of use cases for a type operator 'optionalize' like @RyanCavanaugh suggested - that way I can declare new types and declare variables of optionalized types.

There are already two issues that propose type operators: #2710, #3779

The problem with super here is that it's inaccurate in several ways:
declare function setState<T super { s1: { x: Derived; y: number; } }>(s: T);

setState( { x1: 32 }); // No error, but wrong
setState( { s1: { y: 42 } }); // No error, but wrong
setState( { s1: { x: new Base(), y: 32 } }); // No error, but wrong

I also want to say that this use case is important to other libraries as well (and I think the title is a bit misleading, really what the intent of this is the way to operate on a type to make all its members optional).
I think it is a common pattern to pass an object literal to a constructor (or factory) function that can be any of the public properties of the instance class, which is then mixed in upon construction.  I ran into this issue when trying to type Dojo 1 Dijits.  The only option, if I wanted to type the constructor functions, is to create a wholly separate interface which has all optional members.
I agree super might give the wrong semantic impression.  I suspect optionalize or optional would be more semantically clear:
class A {
  foo: string;
  bar(): string { return 'bar'; };
  constructor<O optionalize this>(options: O) { };
}

type OptionalA = optionalize A;

/*or*/

class B {
  foo: string;
  bar(): string { return 'bar'; };
  constructor(options: $Optionalize<this>) { };
}

type OptionalB = $Optionalize<A>;

Whatever we do here also applies to Object.assign that was introduced in ES2015.

Somewhere here in issues I see this proposal for similar case:
function assign<R extends A,B,C>(a:A, b:B, c:C):R

Isn't it the similar thing?

@Strate I don't think so, see the first use case of post #6218.  The first use case was solved like you said but the setState() use case wasn't.

We'd need type operators to solve this, which is a huge work item; Workaround of specifying all-optionals in state definition, which isn't too bad.

Are type operators even on the table, or maybe tracked in a separate issue?

type operators keep coming up in different context. They are not totally dismissed, just not in the short term. the concern is the effort needed to add one of these, as it goes deep in the type system.

@mhegazy you're missing the point - all-optionals is NOT a workaround, you haven't understood the problem at all. Even if you specify all optionals, the compiler will not accept the code and you will have to cast to any.  This affects everybody using React and subclassing. Even if this is not on the near term roadmap please keep this issue open.

@RyanCavanaugh please help

@rogierschouten with what specifically?

Another possible solution could be allowing having member-level constraints for types defined in containing interface/class #1290
class ReactComponent<S extends {}> {
    protected _state: S;

    /**
     * This method accepts any supertype of S
     */
    protected setState<T, S extends T>(newState: T): void {
    }
}

Currently it introduces new S generic type parameter which have no connection with S from the class. But if it'd possible, T would be inferred from newState and then S wouldn't meet the constraint.

Yes, I thought of some sort of variation of F-bounded polymorphism (#5949) might help solve this problem, I think the problem here is how to set a type that cannot be resolved, even recursively, until the method's type is resolved.  S's type is essentially a moving target.

Agree with @Igorbek. I thought F-bounded polymorphism would just work in this case without the need for new keywords and type operators.

With Typescript 2.0 and strict null checks, the workaround of using all optional fields in the React State type definition means that any functions using state need to be cast to their non-null type before being used. This makes strict null checks really difficult to adopt for React developers.
We really need a better solution here. Back to F-bounded polymorphism, super or optionalize keywords... or some other type operator.

A little bit of testing with Typescript 2 beta shows some inconsistencies with f-bounded polymorphism.  The following code, useful for type checking a Object.assign type function works OK and picks up the invalid function call:
interface IState {
	readonly foo:number;
	readonly bar:string;
};

function merge<T,S extends T>( s: S, s2: T ) : T {
	return Object.assign({},s,s2);
}

const s : IState = { foo:1, bar:"two"};

console.log("merge foo=3",merge(s, { foo:3}));
console.log("merge bar=OK",merge(s, { bar:"OK"}));
console.log("merge invalid=2",merge(s, { invalid:2})); // <-- error

This is great and shows how this can be used to optionalize the type of IState.
However, in the use-case of a React style setState this doesn't work and doesn't produce any compile errors:
class Component  {
 	protected state:IState;
	constructor() {
		this.state = { foo:3, bar:"two"};
	}
	protected setState<P,IState extends P>(newState:P) {
	}

	public doSomething() {
		this.setState({foo:10});
		this.setState({invalid:2}); // !! should produce a compile time error, invalid not part of IState
	}
}

Even though the types of the function for setState have been explicitly spelled out, the compiler fails to flag that the type {invalid:number} is not a super-type of IState.
If I change the code above slightly and change the definition of setState so that the state type is added as a parameter to the function like this:
	protected setState<P,IState extends P>(newState:P,state:IState) {
	}

The invalid call to setState now fails as expected:
		this.setState({foo:10},this.state);
		this.setState({invalid:2},this.state);  // compile error !! Problem caught.

So it seems that f-bounded polymorphism only works for types used in function parameters. If this were to be fixed then it would solve the react setState issue and make strict null checking adoptable for react based code.

@joewood  Your function code doesn't work for all cases either. If you had a legitimate optional property in your State, then you wouldn't be able to update it ( { a?: number} is not a valid subtype of { a: number } ).

@AlexGalays  true, but wouldn't it more correct to say that the state was number | undefined than making it optional?

@joewood Nice! I was still using void as the type containing undefined, looks like the new undefined type works better.

@joewood
Your example doesn't work with other combinations, like unions
False positive
interface IState {
    readonly foo:number;
    readonly bar: 'aa' | 'bb';
};

const s : IState = { foo:1, bar: "aa"};

// Ok to compile this, but shouldn't
merge(s, { bar: 'thisShouldntBeAssignable'})

Or:
"False" negative
type A = { _isA: boolean }
type B = { _isB: boolean }

interface IState {
    readonly foo:number;
    readonly bar: A | B;
};

const s : IState = { foo:1, bar: { _isA: true }};

// Doesn't compile, as an union cannot be assigned to just one of its type
merge(s, { bar: { _isB: true }})

This is sad :(  I really wanted to have usable deep jSON updates.

@joewood
Your example doesn't work with other combinations, like unions
False positive
interface IState {
    readonly foo:number;
    readonly bar: 'aa' | 'bb';
};

const s : IState = { foo:1, bar: "aa"};

// Compiler is happy, but ideally shouldn't
merge(s, { bar: 'thisShouldntBeAssignable'})

Or:
"False" negative
type A = { _isA: boolean }
type B = { _isB: boolean }

interface IState {
    readonly foo:number;
    readonly bar: A | B;
};

const s : IState = { foo:1, bar: { _isA: true }};

// Doesn't compile, as an union cannot be assigned to just one of its types
merge(s, { bar: { _isB: true }})

This is sad :(  I really wanted to have usable deep JSON updates.
I think it's important not to give the TS team the wrong impression: There are no known workarounds for this.

I think there's a couple of things going on with your examples, and agree - this really isn't ideal.
For your first example, I think this relates to the rule where mutable bindings are widened for string literal types. See these issues for the details on that one https://github.com/Microsoft/TypeScript/issues/9489 and https://github.com/Microsoft/TypeScript/pull/5185. I would argue that no widening should apply to a constant expression - it's hard to argue that the compiler is doing the right thing here.
The second example is down to the fact that type { bar : B} is not a valid super of { bar : A | B}. So the compiler is correct here and the only suggestion I have is to cast the implicit type: merge(s, { bar: { _isB: true } as A | B}).

I completely agree with your points. Also there might be quite a few other corner cases I didn't find yet.
It just shows we badly need some kind of type modifier that takes a type and return the same type with all its properties optional, recursively; or something along those lines (A la flow's $Shape)

While this is declined, #4889, which is very similar and will solve this problem is being actively discussed and @RyanCavanaugh has indicated it is possible candidate for TypeScript 2.1.

Thanks for the link, I would love for this to be in 2.1

I can't follow the entire discussion here, but this seems to be related to the reason why I can't find a construct that allows me to say:
class Message {
    public static TypeID: string;
    public TypeID: string;

    public Sequence: number;

    constructor() {
    }
}

and then:
public receive<T extends Message>(rcvType: T, handler: (msg: T) => void): void {...}

Such that the "type" I'm specifying for T will work.  For example:
class SomeMessage extends Message {
    public static TypeID = "Messages.Commands.SomeMessage";
    public TypeID = "Messages.Commands.SomeMessage";

    constructor(public Payload: string){
        super();
    }
}

This is currently generating the error:
receive(SomeMessage, (msg: SomeMessage) => {
    console.log(msg.Payload);
});

The type argument for type parameter 'T' cannot be inferred from the usage. Consider specifying the type arguments explicitly.
  Type argument candidate 'typeof SomeMessage' is not a valid type argument because it is not a supertype of candidate 'SomeMessage'.
    Property 'prototype' is missing in type 'SomeMessage'.

I can shift various and sundry things around, but I cannot find a combination that:
a) doesn't complain
b) explicitly ties the two types such that they must be the same type (I can specify things in a way that two different values for rcvType and handler/msg will work, where the intent is that they are the same)
FWIW, rcvType is important because it's used internally to set things up.  I'd also love if I could just not specify rcvType (but I realize type erasure precludes that).

Looks like this has been resolved with #12114.

I'm still trying to digest this PR...
On Wed, Nov 16, 2016 at 6:17 PM, Dibyo Majumdar<EMAIL_ADDRESS>wrote:

Looks like this has been resolved with #12114
https://github.com/Microsoft/TypeScript/pull/12114.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/6613#issuecomment-261135216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-vl_bEXaisDZ_JaeaRwVSdpr1lC7CPks5q-7kcgaJpZM4HL6Cd
.

#12793 should have solved the react problem.  Is there something still open here about Object.assign, or is Pick<...> good enough for it too?

Object.assign don't want Pick<> as you can merge any kind of objects into any kind of object.
If you want to update an object with only objects of the same shape, then you will want to code something that looks a lot like the solution in #12793 indeed.
I think the only issue with the current Object.assign type definition is when the right hand side object has a key with a different type. Instead of it completely replacing the initial type (like in the implementation) the result becomes the union of both types, which sometimes don't even make sense (e.g  number & string)

#10727 would fix it because type of Obejct.assign(a, b) is exactly type of {...a, ...b}.

relevant discussion about distinguishing missing and undefined is tracked in #16524

Fixed with mapped types. Please log new issues if you find any shortcomings in this area


Implement Display for Coin

Closes #899

By the way, we have parsers for this format in CosmJS: https://github.com/cosmos/cosmjs/blob/main/packages/amino/src/coins.ts#L22-L38


libeduvpn-common: 2.0.1 -> 2.0.2

Description of changes
bumped library used for eduvpn-client
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Thanks both!


add deleted condition for Update operation

fixes #1208

Codecov Report

Merging #1249 into master will increase coverage by 0.13%.
The diff coverage is 79.31%.

@@            Coverage Diff             @@
##           master    #1249      +/-   ##
==========================================
+ Coverage   57.34%   57.47%   +0.13%
==========================================
  Files          43       43
  Lines        7797     7812      +15
==========================================
+ Hits         4471     4490      +19
+ Misses       2771     2769       -2
+ Partials      555      553       -2

Impacted Files
Coverage Δ

session_update.go
57.09% <79.31%> (+1.4%)
:arrow_up:

engine_cond.go
60.26% <0%> (+3.97%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c790592...588833a. Read the comment docs.


New version: Spotify.Spotify version <IP_ADDRESS>4.gccacfc8c

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run

@wingetbot rerun

/azp run

@JohnMcPMS we need some waivers here https://github.com/microsoft/winget-pkgs/pulls?q=is%3Apr+is%3Aopen+label%3AAzure-Pipeline-Passed+label%3AValidation-Domain

@wingetbot waivers Add Validation-Domain

@wingetbot waivers Add Policy-Test-2.7


Type missing from product data?

With regular Craft Commerce products I can get the Product Type with {{ product.type }} but this seems to be missing from digital products. There is typeId but I would like to use the Product Type handle. Could this be added? Thank you.

There was always a .productType but have gone ahead and added a .type as an alias:
https://github.com/pixelandtonic/DigitalProducts/commit/0d977cbf0265002b7f5f4d481566af3291a9b3de
is in the latest 1.0.1 release.


Navigate between screens with Compose: Android Basics with Compose

CurrentScreen.title wasn't implemented well into the example code as shown above

Hi @Chrisroid
Thank you for bringing this item to our attention.
The screenshot you provided was most helpful for finding it quickly.
The lesson has been corrected and republished.
Hope you are enjoying the course.
Regards.


[Doc fix][Whats new 2020 link fix]

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/whats-new.md
91
35
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit 5a8d65a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/whats-new.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/whats-new.md
91
35
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit cd29ad6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/whats-new.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add closedir for dangling dir pointer

Fix for coverity issue 1383512, missing closedir on opendir usage

[approve ci]


Feature bookmarks

Description
Added save() function to Outputs, which makes saving the bookmarks or the history easier and which infers the output format from the file's extension.
Fixes #73
Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)
[X] This change requires a documentation update

Checklist:

[X] I have read the contribution guidelines and followed it as far as possible.
[X] I have performed a self-review of my own code (if applicable)
[X] I have made corresponding changes to the documentation (if applicable)
[X] My changes generate no new warnings
[X] Any dependent and pending changes have been merged and published

Codecov Report

Merging #78 into feature-bookmarks will decrease coverage by 1.37%.
The diff coverage is 9.09%.

@@                  Coverage Diff                  @@
##           feature-bookmarks      #78      +/-   ##
=====================================================
- Coverage              56.29%   54.91%   -1.38%
=====================================================
  Files                      3        3
  Lines                    286      295       +9
  Branches                  45       48       +3
=====================================================
+ Hits                     161      162       +1
- Misses                   116      124       +8
  Partials                   9        9

Flag
Coverage Δ

#unittests
54.91% <9.09%> (-1.38%)
:arrow_down:

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

Impacted Files
Coverage Δ

browser_history/cli.py
0.00% <0.00%> (ø)

browser_history/generic.py
56.55% <12.50%> (-2.58%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 022f670...422abf6. Read the comment docs.

I have rebased and squashed your branch so that the git history (log) looks cleaner.
I'll merge it once the CI passes. Thanks!