from:"Kagami"

[blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-03 Thread 'Kagami Rosylight' via blink-dev

 > *Gecko*: Closed Without a Position (
https://github.com/mozilla/standards-positions/issues/143) 

It looks like it's closed with position: "worth prototyping", though? Or is 
there another issue that is closed without position?

On Monday, June 3, 2024 at 6:04:03 PM UTC+2 dad...@google.com wrote:

> Contact emailsl...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://wicg.github.io/private-network-access
>
> Summary
>
> We propose to block access to IP address 0.0.0.0 in advance of PNA 
> completely rolling out. Chrome is deprecating direct access to private 
> network endpoints from public websites as part of the Private Network 
> Access (PNA) specification (
> https://developer.chrome.com/blog/private-network-access-preflight/). 
> Services listening on the localhost (127.0.0.0/8) are considered private 
> according to the specification (
> https://wicg.github.io/private-network-access/#ip-address-space-heading). 
> Chrome's PNA protection (rolled out as part of 
> https://chromestatus.com/feature/5436853517811712) can be bypassed using 
> the IP address 0.0.0.0 to access services listening on the localhost on 
> macOS and Linux. This can also be abused in DNS rebinding attacks targeting 
> a web application listening on the localhost. Since 0.0.0.0 is not used in 
> practice (and should not be used), but was overlooked during 
> https://chromestatus.com/feature/5436853517811712, we're deprecating it 
> separately from the rest of the private network requests deprecation. This 
> will be a Finch (experimental) rollout, rather than a Developer Trial.
>
>
> Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess 
> 
>
> Search tagssecurity , 
> Private 
> Network Access 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Chromium Trial NamePrivateNetworkAccessNullIpAddressAllowed
>
> Origin Trial documentation linkhttps://crbug.com/1300021
>
> WebFeature UseCounter namekPrivateNetworkAccessNullIpAddress
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Closed Without a Position (
> https://github.com/mozilla/standards-positions/issues/143)
>
> *WebKit*: Support (
> https://github.com/WebKit/standards-positions/issues/163)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Goals for experimentation
>
>
>
> Ongoing technical constraints
>
> Eventually, all private network access will be limited according to the 
> developing Private Network Access spec.
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> Flag name on chrome://flagsblock-null-ip-address
>
> Finch feature namePrivateNetworkAccessNullIpAddress
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1300021
>
> Estimated milestones
> Shipping on desktop 133
> Origin trial desktop first 127
> Origin trial desktop last 133
> DevTrial on desktop 127
> Shipping on Android 133
> OriginTrial Android last 133
> OriginTrial Android first 127
> DevTrial on Android 127
> Shipping on WebView 133
> OriginTrial webView last 133
> OriginTrial webView first 127
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5106143060033536
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b0415c6-7195-4d70-b698-f8ec245e5796n%40chromium.org.

[dev-platform] Intent to unship: navigator.vibrate() and Notification.vibrate on Android

2024-05-31 Thread 'Kagami Rosylight' via dev-platform@mozilla.org

As of 2024-05-31 I intent to disable vibration API support on Firefox for 
Android. It's currently supported on Chrome for Android but not on Safari.

Bug to remove: https://bugzilla.mozilla.org/show_bug.cgi?id=1900037

`navigator.vibrate()` on Firefox has been no-op for 4 years and so is 
`Notification.vibrate`, and exposing these APIs has been preventing proper 
feature detection. We hope disabling the features stop the confusion until 
we decide what to do with those APIs.

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/2da6e5fb-7718-43e9-acf1-72d3ac2d63efn%40mozilla.org.

[dev-platform] Intent to ship: Gamepad API outside SecureContext

2024-02-20 Thread Kagami Rosylight

As of Firefox 125 I intend to remove SecureContext restriction from Gamepad 
API.

This restriction is added as a part of cross-browser coordination to 
prevent fingerprinting 
. So far Gecko has 
been the only implementation that shipped the restriction, and we figured 
that requiring HTTPS does not fulfill the previous purpose anymore as almost 
everything is HTTPS now 
. As this 
affects web compatibility, we are lifting the restriction in agreement with 
WebKit .

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1870037
Standard PR: https://github.com/w3c/gamepad/pull/194
Other browsers:
- Blink: They never shipped the restriction but only the warning.
- Safari: Same as Blink, and the warning is being removed: 
https://github.com/WebKit/WebKit/pull/24550
web-platform-tests: https://github.com/web-platform-tests/wpt/pull/44678

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/5fe021b4-9b20-421c-b0ba-73b7271d5a4en%40mozilla.org.

[dev-platform] Re: Intent to unship: DOMRequest

2024-02-19 Thread Kagami Rosylight

Note that DOMRequest cannot be constructed by JS, and as mentioned it's 
never returned from any API, so the only impact here is that 
`window.DOMRequest` will now disappear.

On Monday, February 19, 2024 at 8:42:28 PM UTC+1 Gregory Pappas wrote:

> As of Firefox 124, I intend to turn off support for DOMRequest. This API is
> non-standard and was never implemented by any other browser.
>
> DOMRequest is a Promise-like interface that was implemented before Promises
> existed. DOMRequest was used by a lot of APIs in Firefox OS.
>
> Now that all APIs that returned a DOMRequest object have either been 
> removed
> or updated to return Promises instead, we can remove this non-standard
> interface.
>
> Bug: 1880615 
> Specification: Does not exist
> Preference: dom.domrequest.enabled
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/577c9265-fa65-4329-97b6-985001caedb6n%40mozilla.org.

[blink-dev] Re: Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

2024-01-31 Thread Kagami Rosylight

Oops, the approved emails are now coming. Sorry for the spam, and thank you 
for fixing it 

On Wednesday, January 31, 2024 at 4:10:02 PM UTC+1 Kagami Rosylight wrote:

> Hello, Koji Ishii;
>
> I think this post has a mistake about Mozilla's standards position. 
> https://github.com/mozilla/standards-positions/issues/903 is empty 
> without Mozilla employee's comment, so I think it should be treated as No 
> Signal here.
>
> Thanks!
> On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 Koji Ishii wrote:
>
>> Contact emailsko...@chromium.org, lin...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>>
>> Design docs
>>
>> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>>
>> Summary
>>
>> Applies the kerning to CJK punctuation characters to produce the visually 
>> pleasing typography as defined by JLREQ (Requirements for Japanese Text 
>> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK 
>> punctuation characters include glyph-internal spacing. For example, the CJK 
>> full stop and the CJK close parenthesis usually have glyph-internal 
>> spacings on the right half of their glyph spaces, to give them a constant 
>> advance as other ideographic characters. But when they appear in a row, the 
>> glyph-internal spacings become excessive. This feature adjusts such 
>> excessive spacing. This feature adjusts the glyph-internal spacing for 1) 
>> adjacent characters (pair kerning), 2) at the line start, and 3) at the 
>> line end, by using the font data.
>>
>>
>> Blink componentBlink>Layout>Inline 
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3EInline>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/903)
>>
>> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A 
>> flag is available in Safari Technology Preview.
>>
>> *Web developers*: Positive (
>> https://twitter.com/fontplus/status/1405020633600233479) This tweet 
>> about a web font provider in Japan providing this feature in fonts got 485 
>> likes as of Aug 2023.
>>
>> *Other signals*: Parts of the feature is shipping in Android 13, 
>> ChromeOS 90, iOS 17, MS Word 6.0, and LibreOffice.
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that 
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>>
>> https://wpt.fyi/results/css/css-text?label=experimental=master=text-spacing-trim
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>>
>> Sample links
>> https://output.jsbin.com/figixaq
>>
>> Estimated milestones
>> Shipping on desktop 123
>> Shipping on Android 123
>> Shipping on WebView 123
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or 
>> interop issues. Please list open issues (e.g. links to known github issues 
>> in the project for the feature specification) whose resolution may 
>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5170044014690304
>>
>> Links to previous Intent discussionsIntent to prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKP6u%2BXJ5Vi9aH_AVHJiFPoUM7BhSTYX-oRTPxz87c5XQ%40mail.gmail.com
>>
>> This intent message was generated by Chrome Platform Status 
>> <https://chromestatus.com/>.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b13e70e9-7d27-4399-b11c-af75844a5554n%40chromium.org.

[blink-dev] Re: Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

2024-01-31 Thread Kagami Rosylight


Hi Blink people,

I think there was a misunderstanding while reading Mozilla's standards 
position issue; the issue currently has no response from Mozilla employee 
and thus should be understood as No Signal rather than Positive.

I hope this makes sense.
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 ko...@chromium.org wrote:

> Contact emailsko...@chromium.org, lin...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>
> Design docs
>
> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>
> Summary
>
> Applies the kerning to CJK punctuation characters to produce the visually 
> pleasing typography as defined by JLREQ (Requirements for Japanese Text 
> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK 
> punctuation characters include glyph-internal spacing. For example, the CJK 
> full stop and the CJK close parenthesis usually have glyph-internal 
> spacings on the right half of their glyph spaces, to give them a constant 
> advance as other ideographic characters. But when they appear in a row, the 
> glyph-internal spacings become excessive. This feature adjusts such 
> excessive spacing. This feature adjusts the glyph-internal spacing for 1) 
> adjacent characters (pair kerning), 2) at the line start, and 3) at the 
> line end, by using the font data.
>
>
> Blink componentBlink>Layout>Inline 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/903)
>
> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A 
> flag is available in Safari Technology Preview.
>
> *Web developers*: Positive (
> https://twitter.com/fontplus/status/1405020633600233479) This tweet about 
> a web font provider in Japan providing this feature in fonts got 485 likes 
> as of Aug 2023.
>
> *Other signals*: Parts of the feature is shipping in Android 13, ChromeOS 
> 90, iOS 17, MS Word 6.0, and LibreOffice.
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
>
> https://wpt.fyi/results/css/css-text?label=experimental=master=text-spacing-trim
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>
> Sample links
> https://output.jsbin.com/figixaq
>
> Estimated milestones
> Shipping on desktop 123
> Shipping on Android 123
> Shipping on WebView 123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5170044014690304
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKP6u%2BXJ5Vi9aH_AVHJiFPoUM7BhSTYX-oRTPxz87c5XQ%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2665508-12c3-46c1-8b38-094aa9db320bn%40chromium.org.

[blink-dev] Re: Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

2024-01-31 Thread Kagami Rosylight

Hello, Koji Ishii;

I think this post includes a mistake about Mozilla's standards position. 
https://github.com/mozilla/standards-positions/issues/903 does not have any 
comment from Mozilla employee so far, so I think it should be No Signal 
instead.
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 Koji Ishii wrote:

> Contact emailsko...@chromium.org, lin...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>
> Design docs
>
> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>
> Summary
>
> Applies the kerning to CJK punctuation characters to produce the visually 
> pleasing typography as defined by JLREQ (Requirements for Japanese Text 
> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK 
> punctuation characters include glyph-internal spacing. For example, the CJK 
> full stop and the CJK close parenthesis usually have glyph-internal 
> spacings on the right half of their glyph spaces, to give them a constant 
> advance as other ideographic characters. But when they appear in a row, the 
> glyph-internal spacings become excessive. This feature adjusts such 
> excessive spacing. This feature adjusts the glyph-internal spacing for 1) 
> adjacent characters (pair kerning), 2) at the line start, and 3) at the 
> line end, by using the font data.
>
>
> Blink componentBlink>Layout>Inline 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/903)
>
> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A 
> flag is available in Safari Technology Preview.
>
> *Web developers*: Positive (
> https://twitter.com/fontplus/status/1405020633600233479) This tweet about 
> a web font provider in Japan providing this feature in fonts got 485 likes 
> as of Aug 2023.
>
> *Other signals*: Parts of the feature is shipping in Android 13, ChromeOS 
> 90, iOS 17, MS Word 6.0, and LibreOffice.
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
>
> https://wpt.fyi/results/css/css-text?label=experimental=master=text-spacing-trim
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>
> Sample links
> https://output.jsbin.com/figixaq
>
> Estimated milestones
> Shipping on desktop 123
> Shipping on Android 123
> Shipping on WebView 123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5170044014690304
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKP6u%2BXJ5Vi9aH_AVHJiFPoUM7BhSTYX-oRTPxz87c5XQ%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dde957df-0f82-42ce-82b0-962b1cf67a6en%40chromium.org.

[blink-dev] Re: Intent to Ship: CJK punctuation kerning: the CSS `text-spacing-trim` property

2024-01-31 Thread Kagami Rosylight

Hello, Koji Ishii;

I think this post has a mistake about Mozilla's standards position. 
https://github.com/mozilla/standards-positions/issues/903 is empty without 
Mozilla employee's comment, so I think it should be treated as No Signal 
here.

Thanks!
On Wednesday, January 31, 2024 at 6:38:19 AM UTC+1 Koji Ishii wrote:

> Contact emailsko...@chromium.org, lin...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
>
> Design docs
>
> https://docs.google.com/document/d/146Bupkg3nrNALL3bm8UElRd0vsLVH5807xubsnrthDw/edit?usp=sharing
>
> Summary
>
> Applies the kerning to CJK punctuation characters to produce the visually 
> pleasing typography as defined by JLREQ (Requirements for Japanese Text 
> Layout) and CLREQ (Requirements for Chinese Text Layout). Many CJK 
> punctuation characters include glyph-internal spacing. For example, the CJK 
> full stop and the CJK close parenthesis usually have glyph-internal 
> spacings on the right half of their glyph spaces, to give them a constant 
> advance as other ideographic characters. But when they appear in a row, the 
> glyph-internal spacings become excessive. This feature adjusts such 
> excessive spacing. This feature adjusts the glyph-internal spacing for 1) 
> adjacent characters (pair kerning), 2) at the line start, and 3) at the 
> line end, by using the font data.
>
>
> Blink componentBlink>Layout>Inline 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/907
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/903)
>
> *WebKit*: Positive (https://github.com/w3c/csswg-drafts/issues/4246) A 
> flag is available in Safari Technology Preview.
>
> *Web developers*: Positive (
> https://twitter.com/fontplus/status/1405020633600233479) This tweet about 
> a web font provider in Japan providing this feature in fonts got 485 likes 
> as of Aug 2023.
>
> *Other signals*: Parts of the feature is shipping in Android 13, ChromeOS 
> 90, iOS 17, MS Word 6.0, and LibreOffice.
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
>
> https://wpt.fyi/results/css/css-text?label=experimental=master=text-spacing-trim
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463891
>
> Sample links
> https://output.jsbin.com/figixaq
>
> Estimated milestones
> Shipping on desktop 123
> Shipping on Android 123
> Shipping on WebView 123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5170044014690304
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKP6u%2BXJ5Vi9aH_AVHJiFPoUM7BhSTYX-oRTPxz87c5XQ%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6f18c041-ba43-435f-8b1b-35ae917775c2n%40chromium.org.

[dev-platform] Intent to ship: Enable pointer events on disabled form elements

2024-01-26 Thread Kagami Rosylight

 

As of 2024-01-26 I intend to turn 
`dom.forms.always_allow_pointer_events.enabled` on by default on all 
platforms. This pref allows firing pointer events on disabled form elements 
e.g.  and .

This has been in discussion in https://github.com/whatwg/html/issues/2368 
and https://github.com/whatwg/html/issues/5886, and both Chrome and Safari 
are now shipping the behavior in a good consensus.

*Bug to turn on by default*: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1653882 

Standard: We still need to adjust the HTML spec to reflect the consensus. 
The updated behavior is already covered on WPT: 
https://wpt.fyi/results/html/semantics/disabled-elements

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/1c8f730e-131e-454f-88e6-2373cf86a3e3n%40mozilla.org.

[dev-platform] Intent to prototype and ship: Compression Streams

2023-03-27 Thread Kagami Rosylight

As of March 25 (past, yes ) I intend to prototype and ship Compression
Streams. This feature allows JavaScript to compress and decompress some
industry standard compression formats, namely deflate/deflate-raw/gzip.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1823619
Specification: https://wicg.github.io/compression/
Standards body: Still in WICG yet and it's not clear to which body it will
go. See https://github.com/WICG/compression/issues/32 for details.
Platform coverage: All
Preference: dom.compression_streams.enabled (on by default)
Mozilla standard position: positive.
https://mozilla.github.io/standards-positions/#compression-streams
Other browsers: Shipped in Chrome 80, shipping in Safari 16.4 (still in
beta)
Web platform tests: https://wpt.fyi/results/compression (All green!)

How stable is the spec: There have been minimal changes with no visible
behavior change since 2019/2020.
Security & privacy concerns: This uses an external library named zlib.
While this library is old, mature, and being used by nearly everyone
including multiple existing components in Gecko, extra fuzzing will still
be helpful. The same library is used in Blink and WebKit to implement this
feature. For privacy, this does not expose any system configuration. See
also https://wicg.github.io/compression/#privacy-security.
Web developer use cases: Zip files can be created without depending on
JS/wasm compression libraries, for example.
Example: https://wicg.github.io/compression/#examples

--
You received this message because you are subscribed to the Google Groups
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/f6dbb206-2fd6-40f8-a563-e027eb2cn%40mozilla.org.

[dev-platform] chrome-privilieged scripts: `instanceof` operator against DOM interfaces will soon be strictly rejected

2022-08-24 Thread Kagami Rosylight

Hi people,

If you are currently writing/maintaining chrome-privileged scripts then
this post is for you. If not you can ignore this.

The mozilla/use-Instance ESLint rule will soon be improved to strictly
reject any use of `instanceof` call against DOM interface within chrome
scripts. This is because we traditionally used [Symbol.hasInstance] to
allow cross-context instanceof and we want to unship it to make it
standard-compliant. Unfortunately it is nontrivial to pick and replace the
faulty instanceof uses, so we decided to replace all the uses with the
equivalent chrome-only isInstance() function.

Non-privileged scripts e.g. mochitest files and general websites will not
be affected.

Rejected: foo instanceof Node
Preferred: Node.isInstance(foo)

You can opt-out if you strictly need the context-strict standard instanceof
with the following comment:

// eslint-disable-next-line mozilla/use-isInstance
foo instanceof Node

See also:
* The relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1695435
* docs for use-isInstance rule:
https://firefox-source-docs.mozilla.org/code-quality/lint/linters/eslint-plugin-mozilla/use-isInstance.html
* the 2021 intent-to-unship:
https://groups.google.com/g/mozilla.dev.platform/c/PSEPdL0MbvM/m/9Y_fOnt5AAAJ

[dev-platform] Re: Intent to prototype and ship: TextDecoderStream and TextEncoderStream

2022-08-10 Thread Kagami Rosylight

Hi Brian,
Didn't know there's no position, sorry! It's a bit late but I just filed 
one: https://github.com/mozilla/standards-positions/issues/673

On Wednesday, August 10, 2022 at 11:14:59 PM UTC+2 Brian Grinstead wrote:

> Hi Kagami,
> I don't see a standards position set for this. Could you link to one if it 
> already exists or file a new issue if not?
>
> Thanks,
> Brian
>
> On Wednesday, August 10, 2022 at 11:14:33 AM UTC-7 Kagami Rosylight wrote:
>
>> *Summary*: As of Firefox 105 I intend to prototype and ship 
>> TextDecoderStream and TextEncoderStream which ease processing text streams 
>> via pipeThrough().
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1486949
>> *Specification*: 
>> https://encoding.spec.whatwg.org/#interface-textdecoderstream and 
>> https://encoding.spec.whatwg.org/#interface-textencoderstream
>> *Platform coverage*: All
>> *Other browsers*: Shipped by Chrome 71 and Safari 14.1.
>> *web-platform-tests*: https://wpt.live/encoding/streams/
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/4014055c-231d-4214-b17f-904c4c030b9fn%40mozilla.org.

[dev-platform] Intent to prototype and ship: TextDecoderStream and TextEncoderStream

2022-08-10 Thread Kagami Rosylight

 

*Summary*: As of Firefox 105 I intend to prototype and ship 
TextDecoderStream and TextEncoderStream which ease processing text streams 
via pipeThrough().
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1486949
*Specification*: 
https://encoding.spec.whatwg.org/#interface-textdecoderstream and 
https://encoding.spec.whatwg.org/#interface-textencoderstream
*Platform coverage*: All
*Other browsers*: Shipped by Chrome 71 and Safari 14.1.
*web-platform-tests*: https://wpt.live/encoding/streams/

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/92ebf018-9900-4fab-b4c2-a03216f9b7c0n%40mozilla.org.

[dev-platform] Intent to ship: Transferable streams

2022-06-15 Thread Kagami Rosylight

As of Firefox 103 I intend to turn dom.streams.transferable.enabled on by 
default on all platforms. It has been supported by Blink since 2020 while 
not by WebKit yet.

*Bug to turn on by default*: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1770627

Standard: link to the standard: https://streams.spec.whatwg.org/#rs-transfer, 
https://streams.spec.whatwg.org/#ws-transfer, https://streams.spec.whatwg.
org/#ts-transfer 

This feature was previously announced in this "Intent to prototype" thread: 
https://groups.google.com/a/mozilla.org/g/dev-platform/c/ACDDMOE-PPM.

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/cfffdb91-7517-4a36-90b7-065e28ec67d9n%40mozilla.org.

Re: [dev-platform] Re: Deprecating SpiderMonkey Rooting Typedefs

2022-06-01 Thread Kagami Rosylight

Currently the use of [[deprecated]] is disallowed, though:
https://firefox-source-docs.mozilla.org/code-quality/coding-style/using_cxx_in_firefox_code.html#notes

> |[[deprecated]]|: If we have deprecated code, we should be removing
it rather than marking it as such. Marking things as |[[deprecated]]|
also means the compiler will warn if you use the deprecated API, which
turns into a fatal error in our automation builds, which is not helpful.

On 01/06/2022 14:38, Mirko Brodesser wrote:

On Friday, May 27, 2022 at 7:45:18 PM UTC+2 Bobby Holley wrote:

Hi Folks,

We've long had two ways to specify SpiderMonkey rooting types in
C++: via the canonical definition (e.g., JS::Handle)
and the a set of shortcut typedefs defined in TypeDecls.h (e.g.,
JS::HandleObject).

Thus far we have relied on a loose cultural understanding of when
and where to use each variant, but this approach inevitably
creates distracting consistency problems, and is thus something
we're moving away from. As the C++ style owner, I would like to
resolve this specific issue with consistent guidance.

I've spoken with a number of engineers, and the conversations lean
in favor of eliminating the typedefs, because:
* They don't improve understandability or flexibility, and
sometimes hinder them.
* Consistency around typedef availability and naming for more
complex and esoteric types is an ongoing headache.
* Needing a separate header to access the typedefs is occasionally
cumbersome.
* We don't shortcut other commonly-used handles like RefPtr and
already_AddRefed.

I do think the typedefs improve readability to some degree, but
that those benefits are outweighed by the simplicity and
consistency advantages of eliminating them.

Please let me know if there are important considerations that
appear to have been overlooked. Absent further discussion I plan
to update the style guide next week, and we can proceed with
eliminating the typedefs from the code as time permits.

Just for the sake of completeness, one could use C++14's
`[[deprecated]]` keyword [1] here. Mentioning it, because it's
currently rarely used in Gecko [2].

[1] https://en.cppreference.com/w/cpp/language/attributes/deprecated
[2]
https://searchfox.org/mozilla-central/search?q=%5B%5Bdeprecated%5D%5D==true=false

Mirko

Thanks,
Bobby

--
You received this message because you are subscribed to a topic in the
Google Groups "dev-platform@mozilla.org" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/mozilla.org/d/topic/dev-platform/7BuPwiBdMo8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/5aff66bd-3d42-41b3-9790-70dbf52aa744n%40mozilla.org
.

[dev-platform] Re: Intent to ship: TransformStreams and ReadableStream.pipeThrough

2022-05-19 Thread Kagami Rosylight

This will be on version 102.

On Thursday, May 19, 2022 at 12:11:25 AM UTC+2 Kagami Rosylight wrote:

> Summary: We want to ship TransformStream and ReadableStream.pipeThrough 
> method,  which was prototyped in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1764099. 
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1767507
>
> Specification:
> - https://streams.spec.whatwg.org/#ts-class
> - https://streams.spec.whatwg.org/#rs-pipe-through
>
> Platform coverage: All
>
> Preference: Both are behind `dom.streams.transform_streams.enabled`.
>
> Other browsers: 
> - TransformStream: Shipped in Chrome 67 and Safari 14.1
> - pipeThrough: Shipped in Chrome 59 and Safari 10.1
>
> web-platform-tests:
> - https://wpt.live/streams/transform-streams/
> - https://wpt.live/streams/piping/pipe-through.any.js
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/e3b41a95-f560-4823-b72f-86a34322a9efn%40mozilla.org.

[dev-platform] Intent to prototype: Transferable streams

2022-05-19 Thread Kagami Rosylight

 

*Summary*: We want to let stream objects be transferable via postMessage().

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1659025

*Specification*: https://streams.spec.whatwg.org/#rs-transfer, 
https://streams.spec.whatwg.org/#ws-transfer, 
https://streams.spec.whatwg.org/#ts-transfer

*Standards Body*: WHATWG

*Platform coverage*: All

*Preference*: dom.streams.transferable.enabled (will be initially enabled 
only on Nightly)

*Other browsers*: Shipped on Chrome in 2020 
, no 
signal from Safari.

*web-platform-tests*: https://wpt.live/streams/transferable/

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/7bfd9f76-191f-48b7-bd94-517dc836d2e9n%40mozilla.org.

[dev-platform] Intent to ship: TransformStreams and ReadableStream.pipeThrough

2022-05-18 Thread Kagami Rosylight

 
Summary: We want to ship TransformStream and ReadableStream.pipeThrough 
method,  which was prototyped in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1764099. 

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1767507

Specification:
- https://streams.spec.whatwg.org/#ts-class
- https://streams.spec.whatwg.org/#rs-pipe-through

Platform coverage: All

Preference: Both are behind `dom.streams.transform_streams.enabled`.

Other browsers: 
- TransformStream: Shipped in Chrome 67 and Safari 14.1
- pipeThrough: Shipped in Chrome 59 and Safari 10.1

web-platform-tests:
- https://wpt.live/streams/transform-streams/
- https://wpt.live/streams/piping/pipe-through.any.js

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/1ff9de47-b38e-4fbb-bb3d-10e171aabc40n%40mozilla.org.

[dev-platform] Intent to unship: window.sidebar

2022-05-09 Thread Kagami Rosylight

 

As of version 102 I intend to remove window.sidebar. This has only been 
supported by Gecko.

*Bug to remove*: https://bugzilla.mozilla.org/show_bug.cgi?id=1768486

*Pref*: dom.window.sidebar.enabled

https://bugzilla.mozilla.org/show_bug.cgi?id=1717612 already disabled it on 
nightly/early beta 11 months ago, and since then we saw no regression but a 
webcompat case where disabling window.sidebar fixes the issue. (
https://bugzilla.mozilla.org/show_bug.cgi?id=1768345)

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/3302cbf2-b044-43a3-9d87-76e03ceec70an%40mozilla.org.

[dev-platform] Intent to unship: IDBDatabase.createMutableFile() and the relevant classes

2022-05-09 Thread Kagami Rosylight

 

As of version 102 I intend to remove IDBDatabase.createMutableFile and 
IDBMutableFile/IDBFileHandle/IDBFileRequest. They have only been supported 
by Gecko. 

*Bug to remove*: https://bugzilla.mozilla.org/show_bug.cgi?id=1764771

*Pref*: dom.fileHandle.enabled

Telemetry 

 
shows 0% use of IDBMutableFile.open(). (I separately confirmed 
IDBDatabase.createMutableFile also has 0% use.)

As the deprecation message says 
,
 
support for the equivalent feature will likely be added as File System 
Standard.

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/8bf86ac1-9ace-4189-a450-663f3529159an%40mozilla.org.

[dev-platform] Intent to prototype: TransformStreams and ReadableStream.pipeThrough

2022-04-12 Thread Kagami Rosylight

Summary: We want to prototype TransformStream and 
ReadableStream.pipeThrough method, which are used to transform a given 
stream for another use.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1764099

Specification:
- https://streams.spec.whatwg.org/#ts-class
- https://streams.spec.whatwg.org/#rs-pipe-through

Platform coverage: All

Preference: Both are behind `dom.streams.transform_streams.enabled` which 
will be enabled on Nightly-only for now.

Other browsers: 
- TransformStream: Shipped in Chrome 67 and Safari 14.1
- pipeThrough: Shipped in Chrome 59 and Safari 10.1

web-platform-tests:
- https://wpt.live/streams/transform-streams/
- https://wpt.live/streams/piping/pipe-through.any.js

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/733e7a4f-a0e4-4ced-8078-7906a71e23a7n%40mozilla.org.

[PATCH] D117407: [clang] Add include path for cppwinrt on Windows SDK 10.0.17134+

2022-01-17 Thread Kagami Sascha Rosylight via Phabricator via cfe-commits

saschanaz added a comment.

https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

> Prior to obtaining commit access, it is common practice to request that 
> someone with commit access commits on your behalf. When doing so, please 
> provide the name and email address you would like to use in the Author 
> property of the commit.

Per this paragraph, you can use `Kagami Sascha Rosylight 
`. In parallel, I just requested my access 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117407/new/

https://reviews.llvm.org/D117407

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117407: [clang] Add include path for cppwinrt on Windows SDK 10.0.17134+

2022-01-17 Thread Kagami Sascha Rosylight via Phabricator via cfe-commits

saschanaz added a comment.

> Do you have commit access, or would you like me to commit it for you?

I don't have the access, please do it for me 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117407/new/

https://reviews.llvm.org/D117407

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117407: [clang] Add include path for cppwinrt on Windows SDK 10.0.17134+

2022-01-16 Thread Kagami Sascha Rosylight via Phabricator via cfe-commits

saschanaz added a comment.

That same check decorate_proc_maps.cpp failed on D117405 
 too 樂


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117407/new/

https://reviews.llvm.org/D117407

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117407: [clang] Add include path for cppwinrt on Windows SDK 10.0.17134+

2022-01-15 Thread Kagami Sascha Rosylight via Phabricator via cfe-commits

saschanaz created this revision.
saschanaz added a reviewer: hans.
saschanaz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes https://github.com/llvm/llvm-project/issues/53112 by adding cppwinrt 
to the include path when the SDK version is higher than 10.0.17134.0.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117407

Files:
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/cl-sysroot.cpp


Index: clang/test/Driver/cl-sysroot.cpp
===
--- clang/test/Driver/cl-sysroot.cpp
+++ clang/test/Driver/cl-sysroot.cpp
@@ -17,6 +17,7 @@
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows 
Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}shared"
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows 
Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}um"
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows 
Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}winrt"
+// CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows 
Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}cppwinrt"
 
 // CHECK: "-libpath:[[ROOT]]{{/|}}DIA SDK{{/|}}lib{{/|}}amd64"
 // CHECK: 
"-libpath:[[ROOT]]{{/|}}VC{{/|}}Tools{{/|}}MSVC{{/|}}27.1828.18284{{/|}}lib{{/|}}x64"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1333,6 +1333,15 @@
 AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
   "Include", windowsSDKIncludeVersion,
   "winrt");
+if (major >= 10) {
+  llvm::VersionTuple Tuple;
+  if (!Tuple.tryParse(windowsSDKIncludeVersion) &&
+  Tuple.getSubminor().getValueOr(0) >= 17134) {
+AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
+  "Include", windowsSDKIncludeVersion,
+  "cppwinrt");
+  }
+}
   } else {
 AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
   "Include");


Index: clang/test/Driver/cl-sysroot.cpp
===
--- clang/test/Driver/cl-sysroot.cpp
+++ clang/test/Driver/cl-sysroot.cpp
@@ -17,6 +17,7 @@
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}shared"
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}um"
 // CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}winrt"
+// CHECK: "-internal-isystem" "[[ROOT]]{{/|}}Windows Kits{{/|}}10{{/|}}Include{{/|}}10.0.19041.0{{/|}}cppwinrt"
 
 // CHECK: "-libpath:[[ROOT]]{{/|}}DIA SDK{{/|}}lib{{/|}}amd64"
 // CHECK: "-libpath:[[ROOT]]{{/|}}VC{{/|}}Tools{{/|}}MSVC{{/|}}27.1828.18284{{/|}}lib{{/|}}x64"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1333,6 +1333,15 @@
 AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
   "Include", windowsSDKIncludeVersion,
   "winrt");
+if (major >= 10) {
+  llvm::VersionTuple Tuple;
+  if (!Tuple.tryParse(windowsSDKIncludeVersion) &&
+  Tuple.getSubminor().getValueOr(0) >= 17134) {
+AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
+  "Include", windowsSDKIncludeVersion,
+  "cppwinrt");
+  }
+}
   } else {
 AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, WindowsSDKDir,
   "Include");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[dev-platform] Intent to ship: Web Locks

2021-11-24 Thread Kagami Rosylight

 Web Locks introduces a way to coordinate the usage of resources across 
tabs, workers, etc.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666833, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1740044
Standard: https://wicg.github.io/web-locks/

   - While the specification is still in WICG yet, the W3C WebApps WG will 
   adopt it soon in the next charter. See also 
   https://github.com/w3c/webappswg/issues/73. 

Platform coverage: All
Preference: dom.weblocks.enabled
Other browsers:

   - Chrome: shipped since version 69
   - Safari: no public sign yet (https://github.com/WICG/web-
   locks/issues/55#issuecomment-553257387 
   )

web-platform-tests: https://wpt.live/web-locks/

The previous intent-to-prototype thread: 
https://groups.google.com/a/mozilla.org/g/dev-platform/c/qprlUIF0H48

-- 
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/62db8bbc-c437-419d-80d4-240fba7efc63n%40mozilla.org.

[issue45077] multiprocessing.Pool(64) throws on Windows

2021-10-03 Thread Kagami Sascha Rosylight



Change by Kagami Sascha Rosylight :


--
title: multiprocessing.Pool(64) crashes on Windows -> multiprocessing.Pool(64) 
throws on Windows

___
Python tracker 
<https://bugs.python.org/issue45077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45077] multiprocessing.Pool(64) crashes on Windows

2021-09-01 Thread Kagami Sascha Rosylight



Kagami Sascha Rosylight  added the comment:

The argument-less instantiation also fails, which is worse.

```
>>> multiprocessing.Pool()

>>> Exception in thread Thread-1:
Traceback (most recent call last):
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
973, in _bootstrap_inner
self.run()
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
910, in run
self._target(*self._args, **self._kwargs)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 519, in _handle_workers
cls._wait_for_updates(current_sentinels, change_notifier)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 499, in _wait_for_updates
wait(sentinels, timeout=timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 884, in wait
ready_handles = _exhaustive_wait(waithandle_to_obj.keys(), timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 66
```

--

___
Python tracker 
<https://bugs.python.org/issue45077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45077] multiprocessing.Pool(64) crashes on Windows

2021-09-01 Thread Kagami Sascha Rosylight



New submission from Kagami Sascha Rosylight :

Similar issue as the previous issue 26903.

```
Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> multiprocessing.cpu_count()
64
>>> multiprocessing.Pool(multiprocessing.cpu_count())
Exception in thread Thread-1:
Traceback (most recent call last):

  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
973, in _bootstrap_inner
>>> self.run()
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
910, in run
self._target(*self._args, **self._kwargs)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 519, in _handle_workers
cls._wait_for_updates(current_sentinels, change_notifier)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 499, in _wait_for_updates
wait(sentinels, timeout=timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 884, in wait
ready_handles = _exhaustive_wait(waithandle_to_obj.keys(), timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 66
```

--
components: Windows
messages: 400832
nosy: paul.moore, saschanaz, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: multiprocessing.Pool(64) crashes on Windows
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Intent to ship: AbortSignal.abort()

2021-03-15 Thread Kagami Rosylight

I intend to implement and ship AbortSignal.abort() on all platforms. This is a 
shortcut function to create an aborted AbortSignal, similar to Promise.reject().

Standard: https://github.com/whatwg/dom/pull/960
WPT: https://github.com/web-platform-tests/wpt/pull/28003
Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1698468
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: cross-context @@hasInstance in IDL interfaces

2021-03-04 Thread Kagami Rosylight

https://github.com/heycam/webidl/pull/356 removed custom hasInstance behavior 
in 2017, and the feature has only been shipped by Firefox.

Dropping the support means that JavaScript `instanceof` operator will return 
false when the contexts of the object and the constructor don't match, e.g. the 
object is from an iframe and the constructor is from the top window.

The change will initially be only on Nightly to make sure there won't be any 
significant breakages, and then will propagate to stable versions.

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1360715
WPT: https://wpt.live/WebIDL/ecmascript-binding/has-instance.html
Relevant flag: dom.webidl.crosscontext_hasinstance.enabled
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: HTML element and the context menu feature

2020-12-08 Thread Kagami Rosylight

It was removed from the HTML spec in 2017 because of the lack of implementer 
interest (https://github.com/whatwg/html/pull/2742). There is no other browser 
that implements this feature.

Items to be removed:

* ``
* The `type` attribute of ``
* The `onshow` event handler
* The `contextMenu` attribute of HTMLElement

It will first be hidden behind the flag `dom.menuitem.enabled` and later will 
be completely removed.

Bug to remove: https://bugzilla.mozilla.org/show_bug.cgi?id=1680596 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1372276.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: selectionchange for input/textarea

2020-08-20 Thread Kagami Rosylight

Summary: selectionchange for text controls has been behind the flag `dom.select_events.textcontrols.enabled`, while the behaviour was different from Chrome’s as the events fired at each element instead of `document`. I intend to modify the behaviour to make the events fire at `document` and thus follow Chrome’s behaviour.Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1648944 and https://bugzilla.mozilla.org/show_bug.cgi?id=1309626 Standard: https://github.com/w3c/selection-api/issues/53 Platform coverage: AllPreference: Enabled by default, but still controlled by `dom.select_events.textcontrols.selectionchange.enabled`. Note that the flag is changed to enable `selectstart` separately in the future.Other browsers: Chrome: ShippedSafari: Shippedweb-platform-tests: There is no wpt coverage yet.Blocked by test_driver not allowing intermediate mouse state https://github.com/web-platform-tests/wpt/issues/24944 Secure contexts: No, as other browsers already shipped this without restrictionIs this feature enabled by default in sandboxed iframes?: Yes 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: selectionchange for input/textarea

2020-08-14 Thread Kagami Rosylight

Summary: selectionchange for text controls has been behind the flag 
`dom.select_events.textcontrols.enabled`, while the behaviour was different 
from Chrome’s as the events fired at each element instead of `document`. I 
intend to modify the behaviour to make the events fire at `document` and thus 
follow Chrome’s behaviour.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1648944 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1309626 

Standard: https://github.com/w3c/selection-api/issues/53 

Platform coverage: All

Preference: Enabled by default, but still controlled by 
`dom.select_events.textcontrols.selectionchange.enabled`. Note that the flag is 
changed to enable `selectstart` separately in the future.

Other browsers: 
•   Chrome: Shipped
•   Safari: Shipped

web-platform-tests: There is no wpt coverage yet.
•   Blocked by test_driver not allowing intermediate mouse state 
https://github.com/web-platform-tests/wpt/issues/24944 

Secure contexts: No, as other browsers already shipped this without restriction

Is this feature enabled by default in sandboxed iframes?: Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[issue41053] open() fails to read app exec links

2020-06-20 Thread Kagami Sascha Rosylight



Kagami Sascha Rosylight  added the comment:

It seems libuv and pwsh decided to detect and read them just as symlinks:

https://github.com/libuv/libuv/pull/2812
https://github.com/PowerShell/PowerShell/pull/10331

Could Python do the same?

--

___
Python tracker 
<https://bugs.python.org/issue41053>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41053] open() fails to read app exec links

2020-06-20 Thread Kagami Sascha Rosylight



New submission from Kagami Sascha Rosylight :

After installing Python from Microsoft Store, this fails:

```
>>> open('C:\\Users\\Kagami\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\\python.exe')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 22] Invalid argument: 
'C:\\Users\\Kagami\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\\python.exe'
```

This causes virtualenv to fail on it:

```
INFO: Traceback (most recent call last):
INFO:   File 
"C:/Users/Kagami/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/9a6d8fc/mozjs\third_party\python\virtualenv\virtualenv.py",
 line 2349, in 
INFO: main()
INFO:   File 
"C:/Users/Kagami/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/9a6d8fc/mozjs\third_party\python\virtualenv\virtualenv.py",
 line 703, in main
INFO: create_environment(home_dir,
INFO:   File 
"C:/Users/Kagami/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/9a6d8fc/mozjs\third_party\python\virtualenv\virtualenv.py",
 line 925, in create_environment
INFO: py_executable = os.path.abspath(install_python(
INFO:   File 
"C:/Users/Kagami/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/9a6d8fc/mozjs\third_party\python\virtualenv\virtualenv.py",
 line 1239, in install_python
INFO: shutil.copyfile(executable, py_executable)
INFO:   File "C:\Program 
Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\lib\shutil.py",
 line 261, in copyfile
INFO: with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
INFO: OSError: [Errno 22] Invalid argument: 
'C:\\Users\\Kagami\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\\python.exe'
```

--
components: Windows
messages: 371939
nosy: paul.moore, saschanaz, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: open() fails to read app exec links
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue41053>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

2020-05-24 Thread Kagami Rosylight via Cygwin

From: Marco Atzeri
> `Reply always with mailing list in copy, please
> and bottom posting as standard
>
> On 23.05.2020 18:34, Kagami Rosylight wrote:
> > Hi Marco,
> >
> > >Not clear why you expect that a Windows specific tag as
> > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fgit%2F%3Fp%3Dnewlib-cygwin.git%3Ba%3Dblob%3Bf%3Dwinsup%2Fcygwin%2Fpath.cc%3Bh%3D36aa8278fd8495bdfe5ec82b8c36d7d3d7881ebb%3Bhb%3Drefs%2Fheads%2Fmaster%23l2473data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=Llf8pBA7JBtDEThlvynB7Di1E71xjJnLVUJsEI1N6u8%3Dreserved=0
> >
> >
> > Because Cygwin already supports common reparse points (such as symlinks)
> > and APPEXECLINK is also a common one used by Microsoft Store. This issue
> > causes some CLI tools depending on MSYS2 (which again on Cygwin) to fail
> > calling system Python executable.
> >
> > > that seems a bit short to help third party in properly using it.
> >
> > Good point, and that’s why I only could provide the prior works.
> > REPARSE_DATA_BUFFER_APPEXECLINK in the PowerShell patch shows how the
> > structure look like, but this definitely needs an official
> > documentation. I don’t think it’s a strict blocker given that there are
> > public working patches, though.
> >
> > -Kagami
> >
> > *From: *Marco Atzeri
> > *Sent: *Saturday, 23 May 2020 5:50 PM
> > *To: *cygwin@cygwin.com , sascha...@outlook.com
> > *Subject: *Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
> >
> > On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote:
> > > Hi Cygwin community,
> > >
> > > I found that Cygwin can’t run UWP based CLI tools, as they expose
> > their executables as reparse points with the tag
> > IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support.
> > >
> > > Way to reproduce this issue on Cygwin:
> > >
> > > 1. Install Python from Microsoft Store:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fpython-38%2F9mssztt1n39ldata=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=tJ4DeDmHrHFYPrXIDzLiXZ6vQivQbZVV703SfOqMT%2BM%3Dreserved=0
> > (assuming you don’t already have python3.8 on your PATH.)
> > > 2. Try running `python3.8` on Cygwin. It will say
> > “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8:
> > Permission denied”
> > > 3. Check it’s real path by `get-childitem -path
> > C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on
> > PowerShell. It’s `C:\Program
> > Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
> > > 4. Try running python again with that path. This succeeds.
> > >
> > > I posted this issue on MSYS2 GitHub repo
> > (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2FMSYS2-packages%2Fissues%2F1943data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=9DVvWYnNcgR26LR7p%2FdX2n7uXI8rnL%2BE1nO7ct9ZBF0%3Dreserved=0)
> > but I think Cygwin is the right place to file this.
> > >
> > > Relevant prior works:
> > >
> > > * Python
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fdf2d4a6f3d5da2839c4fc11d31511c8e028daf2cdata=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=PHB5ChU1IX4gfc7NF3XMJqghyoVBic4CJ5fDP1W7LAM%3Dreserved=0
> > > * libuv
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibuv%2Flibuv%2Fcommit%2Fe7ebae26247d2fee0a04547eb7f9aa8f78d4a642data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391504645sdata=rA4UuMyybOHo35N6qPF0OYVxFLk0usYuviUH0NjymlU%3Dreserved=0
> > > * PowerShell
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F10331data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391504645sdata=cW19cfgbotWpc1loOfYJHoIIvFh2zdSSPhdbeRnIGnw%3Dreserved=0
> > >
> > > Thanks,
> > >
> > > -Kagami
> > >
> >
> > Not clear why you expect that a Windows specific tag as
> > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> >
&g

[issue40368] os.path.realpath uppercases Windows drive letter on Python 3.8

2020-04-23 Thread Kagami Sascha Rosylight



Kagami Sascha Rosylight  added the comment:

Should `ntpath.normpath` make the drive letter uppercase?

--

___
Python tracker 
<https://bugs.python.org/issue40368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40368] os.path.realpath uppercases Windows drive letter on Python 3.8

2020-04-23 Thread Kagami Sascha Rosylight



Kagami Sascha Rosylight  added the comment:

I mentioned `os.path.abspath` because `os.path.abspath(".")` on console 
returned `'c:\\Users\\Kagami\\Documents\\GitHub\\gecko-dev'`. It seems this 
incompatibility is partially because MSYS shell prefers lowercase letter for 
Windows path while Windows prefers otherwise.

--

___
Python tracker 
<https://bugs.python.org/issue40368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40368] os.path.realpath uppercases Windows drive letter on Python 3.8

2020-04-22 Thread Kagami Sascha Rosylight



New submission from Kagami Sascha Rosylight :

```
$ python3.7
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os;os.path.realpath('c:/')
'c:\\'
```

```
$ python3.8
Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os;os.path.realpath('c:/')
'C:\\'
```

This behavior is inconsistent with `os.path.abspath` where it always returns 
lowercased drive letter, and also causes a failure in Gecko build script: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1628726

--
messages: 367053
nosy: saschanaz
priority: normal
severity: normal
status: open
title: os.path.realpath uppercases Windows drive letter on Python 3.8
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue40368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [USRP-users] RFNoC multi-driven nets

2019-06-19 Thread Roberto Michio Marques Kagami via USRP-users

Hi, Mitch


I've tested the 118a45d63. Failed (multiple-drivers).

The f6890f22 is good, but only for XG build.

HG option generates another type of error (4 missing pin LOC constraints).

My OS is Ubuntu 16.04.


Regards,

Roberto


De: Mitch Davis 
Enviado: quarta-feira, 19 de junho de 2019 10:13:52
Para: Roberto Michio Marques Kagami
Cc: usrp-users@lists.ettus.com
Assunto: Re: [USRP-users] RFNoC multi-driven nets

Roberto,

Just to clarify, the commit that I used that resulted in successful
build is f6890f227b40687b356c1e6c10d9eec2184691d0

This requires Vivado 2017.4

Did you try f6890f22 or 118a45d63?

I don't have the bandwidth to spare with any bisection to determine
what the actual fault may be.  I've found f6890f22 to yield
satisfactory results.

This is built in a CentOS 7 native install (with EPEL and some other
extra repos enabled).

Regards,

Mitch

On Wed, 2019-06-19 at 17:08 +, Roberto Michio Marques Kagami wrote:
> Hello, Mitch!
>
> I've faced the same problem.
> I've tried the first commit after f6890f22 including Vivado version
> 2018.3 and the error is the same.
> Did you received any reply for this failure?
> I would appreciate any information.
> Thanks!
>
> Regards,
> Roberto Kagami
> De: USRP-users  em nome de Mitch
> Davis via USRP-users 
> Enviado: segunda-feira, 17 de junho de 2019 15:44:07
> Para: usrp-users@lists.ettus.com
> Assunto: Re: [USRP-users] RFNoC multi-driven nets
>
> My apologies for not connecting this message to the OP, I didn't
> register this email account to the list until after the post.
> However,
> Peter had posted that he was having issues building the latest X310
> RFNOC image (with an RFNOC block) with an error of multiple-drivers
> on
> two nets (ce_clk and ce_rst):
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-June/060013.html
>
> I too encountered this same error.
>
> On a hunch, I reverted the repo to the commit just before the Vivado
> 2018.3 update: f6890f227b40687b356c1e6c10d9eec2184691d0
>
> I was able to build the X310 RFNOC image with an RFNOC block using
> that
> commit without failure.
>
> I haven't attempted a bisection yet.  Is there anyone else that has
> observed similar build failures?
>
>
> Regards,
>
> Mitch Davis
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[FFmpeg-cvslog] lavf/matroska: Allow AV1 in WebM

2018-09-21 Thread Kagami Hiiragi

ffmpeg | branch: master | Kagami Hiiragi  | Mon Aug 20 
19:44:40 2018 +0300| [cbe5c7ef386d7bc211823a9bdb17d41d97d4fb71] | committer: 
James Almer

lavf/matroska: Allow AV1 in WebM

Nothing prevents it to work except this check. AV1 is already supported
by Matroska muxer and aomenc produces WebM/AV1 files as well.

Signed-off-by: Kagami Hiiragi 
Signed-off-by: James Almer 

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=cbe5c7ef386d7bc211823a9bdb17d41d97d4fb71
---

 libavformat/matroskaenc.c | 3 ++-
 libavformat/version.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 09a62e1922..76cb124221 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1296,11 +1296,12 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 
 if (mkv->mode == MODE_WEBM && !(par->codec_id == AV_CODEC_ID_VP8 ||
 par->codec_id == AV_CODEC_ID_VP9 ||
+par->codec_id == AV_CODEC_ID_AV1 ||
 par->codec_id == AV_CODEC_ID_OPUS ||
 par->codec_id == AV_CODEC_ID_VORBIS ||
 par->codec_id == AV_CODEC_ID_WEBVTT)) {
 av_log(s, AV_LOG_ERROR,
-   "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT 
subtitles are supported for WebM.\n");
+   "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and 
WebVTT subtitles are supported for WebM.\n");
 return AVERROR(EINVAL);
 }
 
diff --git a/libavformat/version.h b/libavformat/version.h
index d7a1a35069..b346bc3bcd 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR  18
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MICRO 102
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

Re: [FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows

2018-08-31 Thread Kagami Hiiragi

On 31/08/18 18:18, James Almer wrote:
> On 8/31/2018 11:52 AM, Kagami Hiiragi wrote:
>> On 31/08/18 02:58, James Almer wrote:
>>> On 8/20/2018 2:56 PM, Kagami Hiiragi wrote:
>>>> These options are required for multithreaded encoding, because they set
>>>> to zero by default in av1_cx_iface.c.
>>>>
>>>> Signed-off-by: Kagami Hiiragi 
>>>>
>>>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>>>> index 9431179886..55cb7ff72e 100644
>>>> --- a/libavcodec/libaomenc.c
>>>> +++ b/libavcodec/libaomenc.c
>>>> @@ -68,6 +68,8 @@ typedef struct AOMEncoderContext {
>>>>  int static_thresh;
>>>>  int drop_threshold;
>>>>  int noise_sensitivity;
>>>> +int tile_columns;
>>>> +int tile_rows;
>>>>  } AOMContext;
>>>>  
>>>>  static const char *const ctlidstr[] = {
>>>> @@ -75,6 +77,8 @@ static const char *const ctlidstr[] = {
>>>>  [AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
>>>>  [AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
>>>>  [AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
>>>> +[AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
>>>> +[AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
>>>>  [AV1E_SET_COLOR_RANGE]  = "AV1E_SET_COLOR_RANGE",
>>>>  [AV1E_SET_COLOR_PRIMARIES]  = "AV1E_SET_COLOR_PRIMARIES",
>>>>  [AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
>>>> @@ -449,6 +453,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
>>>>  if (ctx->crf >= 0)
>>>>  codecctl_int(avctx, AOME_SET_CQ_LEVEL,  ctx->crf);
>>>>  
>>>> +if (ctx->tile_columns >= 0)
>>>> +codecctl_int(avctx, AV1E_SET_TILE_COLUMNS, ctx->tile_columns);
>>>> +if (ctx->tile_rows >= 0)
>>>> +codecctl_int(avctx, AV1E_SET_TILE_ROWS, ctx->tile_rows);
>>>> +
>>>>  codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
>>>>  codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
>>>>  codecctl_int(avctx, AV1E_SET_TRANSFER_CHARACTERISTICS, 
>>>> avctx->color_trc);
>>>> @@ -746,6 +755,8 @@ static const AVOption options[] = {
>>>>  { "static-thresh","A change threshold on blocks below which they 
>>>> will be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { 
>>>> .i64 = 0 }, 0, INT_MAX, VE },
>>>>  { "drop-threshold",   "Frame drop threshold", offsetof(AOMContext, 
>>>> drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
>>>>  { "noise-sensitivity", "Noise sensitivity", 
>>>> OFFSET(noise_sensitivity), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 4, VE},
>>>> +{ "tile-columns", "Number of tile columns to use, log2", 
>>>> OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
>>>
>>> Why 6? The libaom API doesn't mention a limit, just says the argument
>>> should be in log2 unit, and that it will be capped based on the image size.
>>
>> https://aomedia.googlesource.com/aom/+/1742b043e2269dc1927afe428fbf5a46493e741e/av1/av1_cx_iface.c#298
>>  
>>>> +{ "tile-rows", "Number of tile rows to use, log2", OFFSET(tile_rows), 
>>>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
>>>
>>> And for this one it says the range is [0-2].
>>
>> Who says it? I can pass --tile-rows=6 to aomenc.
> 
> The doxy in the public header:
> https://aomedia.googlesource.com/aom/+/master/aom/aomcx.h#312

I guess it wasn't fixed after
https://aomedia.googlesource.com/aom/+/492c545fad1e1f980d23d79d0372857c60d31458^!/#F1

I don't think ffmpeg should deal with libaom documentation issues...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows

2018-08-31 Thread Kagami Hiiragi

On 31/08/18 02:58, James Almer wrote:
> On 8/20/2018 2:56 PM, Kagami Hiiragi wrote:
>> These options are required for multithreaded encoding, because they set
>> to zero by default in av1_cx_iface.c.
>>
>> Signed-off-by: Kagami Hiiragi 
>>
>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>> index 9431179886..55cb7ff72e 100644
>> --- a/libavcodec/libaomenc.c
>> +++ b/libavcodec/libaomenc.c
>> @@ -68,6 +68,8 @@ typedef struct AOMEncoderContext {
>>  int static_thresh;
>>  int drop_threshold;
>>  int noise_sensitivity;
>> +int tile_columns;
>> +int tile_rows;
>>  } AOMContext;
>>  
>>  static const char *const ctlidstr[] = {
>> @@ -75,6 +77,8 @@ static const char *const ctlidstr[] = {
>>  [AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
>>  [AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
>>  [AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
>> +[AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
>> +[AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
>>  [AV1E_SET_COLOR_RANGE]  = "AV1E_SET_COLOR_RANGE",
>>  [AV1E_SET_COLOR_PRIMARIES]  = "AV1E_SET_COLOR_PRIMARIES",
>>  [AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
>> @@ -449,6 +453,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
>>  if (ctx->crf >= 0)
>>  codecctl_int(avctx, AOME_SET_CQ_LEVEL,  ctx->crf);
>>  
>> +if (ctx->tile_columns >= 0)
>> +codecctl_int(avctx, AV1E_SET_TILE_COLUMNS, ctx->tile_columns);
>> +if (ctx->tile_rows >= 0)
>> +codecctl_int(avctx, AV1E_SET_TILE_ROWS, ctx->tile_rows);
>> +
>>  codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
>>  codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
>>  codecctl_int(avctx, AV1E_SET_TRANSFER_CHARACTERISTICS, 
>> avctx->color_trc);
>> @@ -746,6 +755,8 @@ static const AVOption options[] = {
>>  { "static-thresh","A change threshold on blocks below which they 
>> will be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { 
>> .i64 = 0 }, 0, INT_MAX, VE },
>>  { "drop-threshold",   "Frame drop threshold", offsetof(AOMContext, 
>> drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
>>  { "noise-sensitivity", "Noise sensitivity", OFFSET(noise_sensitivity), 
>> AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 4, VE},
>> +{ "tile-columns", "Number of tile columns to use, log2", 
>> OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
> 
> Why 6? The libaom API doesn't mention a limit, just says the argument
> should be in log2 unit, and that it will be capped based on the image size.

https://aomedia.googlesource.com/aom/+/1742b043e2269dc1927afe428fbf5a46493e741e/av1/av1_cx_iface.c#298
 
>> +{ "tile-rows", "Number of tile rows to use, log2", OFFSET(tile_rows), 
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
> 
> And for this one it says the range is [0-2].

Who says it? I can pass --tile-rows=6 to aomenc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows

2018-08-20 Thread Kagami Hiiragi

These options are required for multithreaded encoding, because they set
to zero by default in av1_cx_iface.c.

Signed-off-by: Kagami Hiiragi 

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 9431179886..55cb7ff72e 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -68,6 +68,8 @@ typedef struct AOMEncoderContext {
 int static_thresh;
 int drop_threshold;
 int noise_sensitivity;
+int tile_columns;
+int tile_rows;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -75,6 +77,8 @@ static const char *const ctlidstr[] = {
 [AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
 [AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
 [AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
+[AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
+[AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
 [AV1E_SET_COLOR_RANGE]  = "AV1E_SET_COLOR_RANGE",
 [AV1E_SET_COLOR_PRIMARIES]  = "AV1E_SET_COLOR_PRIMARIES",
 [AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
@@ -449,6 +453,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
 if (ctx->crf >= 0)
 codecctl_int(avctx, AOME_SET_CQ_LEVEL,  ctx->crf);
 
+if (ctx->tile_columns >= 0)
+codecctl_int(avctx, AV1E_SET_TILE_COLUMNS, ctx->tile_columns);
+if (ctx->tile_rows >= 0)
+codecctl_int(avctx, AV1E_SET_TILE_ROWS, ctx->tile_rows);
+
 codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
 codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
 codecctl_int(avctx, AV1E_SET_TRANSFER_CHARACTERISTICS, avctx->color_trc);
@@ -746,6 +755,8 @@ static const AVOption options[] = {
 { "static-thresh","A change threshold on blocks below which they will 
be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { .i64 = 0 
}, 0, INT_MAX, VE },
 { "drop-threshold",   "Frame drop threshold", offsetof(AOMContext, 
drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
 { "noise-sensitivity", "Noise sensitivity", OFFSET(noise_sensitivity), 
AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 4, VE},
+{ "tile-columns", "Number of tile columns to use, log2", 
OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
+{ "tile-rows", "Number of tile rows to use, log2", OFFSET(tile_rows), 
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
 { NULL }
 };
 
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/matroska: Allow AV1 in WebM

2018-08-20 Thread Kagami Hiiragi

Nothing prevents it to work except this check. AV1 is already supported
by Matroska muxer and aomenc produces WebM/AV1 files as well.

Signed-off-by: Kagami Hiiragi 

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 09a62e1922..76cb124221 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1296,11 +1296,12 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 
 if (mkv->mode == MODE_WEBM && !(par->codec_id == AV_CODEC_ID_VP8 ||
 par->codec_id == AV_CODEC_ID_VP9 ||
+par->codec_id == AV_CODEC_ID_AV1 ||
 par->codec_id == AV_CODEC_ID_OPUS ||
 par->codec_id == AV_CODEC_ID_VORBIS ||
 par->codec_id == AV_CODEC_ID_WEBVTT)) {
 av_log(s, AV_LOG_ERROR,
-   "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT 
subtitles are supported for WebM.\n");
+   "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and 
WebVTT subtitles are supported for WebM.\n");
 return AVERROR(EINVAL);
 }
 
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Open Babel] Openbabel Anaconda package Python 3 support

2018-07-20 Thread Luciano Kagami

Dear support team,Is Anaconda Openbabel package python 3 a "on the fly" conversation? Thank you so much.Best regards,Luciano--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-discuss mailing list
OpenBabel-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

[FFmpeg-cvslog] lavc/libvpxenc: add -row-mt option

2017-03-06 Thread Kagami Hiiragi

ffmpeg | branch: master | Kagami Hiiragi <kag...@genshiken.org> | Thu Mar  2 
21:19:09 2017 +0300| [734d760e2fb2621040edef3536b5935e7bc45351] | committer: 
James Zern

lavc/libvpxenc: add -row-mt option

Signed-off-by: James Zern <jz...@google.com>

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=734d760e2fb2621040edef3536b5935e7bc45351
---

 libavcodec/libvpxenc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index de0d0b6..7c567a0 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -108,6 +108,7 @@ typedef struct VPxEncoderContext {
 int noise_sensitivity;
 int vpx_cs;
 float level;
+int row_mt;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -139,6 +140,9 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
 [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+[VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
+#endif
 #endif
 };
 
@@ -720,6 +724,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 12
 codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+if (ctx->row_mt >= 0)
+codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
+#endif
 }
 #endif
 
@@ -1132,6 +1140,9 @@ static const AVOption vp9_options[] = {
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_BOOL, 
{.i64 = -1}, -1, 1, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-03 Thread Kagami Hiiragi

On 03/03/17 10:18, James Zern wrote:
> On Thu, Mar 2, 2017 at 11:00 AM, Kagami Hiiragi <kag...@genshiken.org> wrote:
>> From ae3856c302284d60761c3ad122ff49b7b9b68114 Mon Sep 17 00:00:00 2001
>> From: Kagami Hiiragi <kag...@genshiken.org>
>> Date: Thu, 2 Mar 2017 21:19:09 +0300
>> Subject: [PATCH] lavc/libvpxenc: add -row-mt option
>>
>> ---
>>  libavcodec/libvpxenc.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> [...]
>>  [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
>>  [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
>>  #endif
>> +#if VPX_ENCODER_ABI_VERSION >= 13
> 
> Better to use #ifdef VPX_CTRL_VP9E_SET_ROW_MT.
> 
>> [...]
>> +#if VPX_ENCODER_ABI_VERSION >= 13
>> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), 
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
>> +#endif
> 
> We could use -thread_type/-slices here, though this is in line with
> vpxenc. I'll leave this open to comment.

Updated. I don't think -slices would fit logically because -row-mt is boolean 
and -slices is integer.

---
 libavcodec/libvpxenc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index de0d0b6bcb..7c567a0d1d 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -108,6 +108,7 @@ typedef struct VPxEncoderContext {
 int noise_sensitivity;
 int vpx_cs;
 float level;
+int row_mt;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -139,6 +140,9 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
 [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+[VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
+#endif
 #endif
 };
 
@@ -720,6 +724,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 12
 codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+if (ctx->row_mt >= 0)
+codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
+#endif
 }
 #endif
 
@@ -1132,6 +1140,9 @@ static const AVOption vp9_options[] = {
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_BOOL, 
{.i64 = -1}, -1, 1, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };
-- 
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread Kagami Hiiragi

On 03/03/17 01:16, Moritz Barsnick wrote:
> On Thu, Mar 02, 2017 at 22:00:36 +0300, Kagami Hiiragi wrote:
>> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), 
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
>^
> Woudn't a _BOOL type accept exactly the same ranges and defaults, with
> the same behavior, but document itself more nicely?
> 
> It would result in
>  -row-mt  E... Row based multi-threading (default auto)
> instead of
>  -row-mt  E... Row based multi-threading (from -1 to 1) 
> (default -1)
> 
> (Guessing, untested.)
> 
> Moritz

I copied description of "lossless" flag, but "frame-parallel" and other
encoders seems to prefer BOOL, you are right.

I'm leaving it up to commiter, it's just s/_INT/_BOOL/.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread Kagami Hiiragi

From ae3856c302284d60761c3ad122ff49b7b9b68114 Mon Sep 17 00:00:00 2001
From: Kagami Hiiragi <kag...@genshiken.org>
Date: Thu, 2 Mar 2017 21:19:09 +0300
Subject: [PATCH] lavc/libvpxenc: add -row-mt option

---
 libavcodec/libvpxenc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index de0d0b6bcb..8eefda5b5b 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -108,6 +108,7 @@ typedef struct VPxEncoderContext {
 int noise_sensitivity;
 int vpx_cs;
 float level;
+int row_mt;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -139,6 +140,9 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
 [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+[VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
+#endif
 #endif
 };
 
@@ -720,6 +724,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 12
 codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+if (ctx->row_mt >= 0)
+codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
+#endif
 }
 #endif
 
@@ -1132,6 +1140,9 @@ static const AVOption vp9_options[] = {
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, 1, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };
-- 
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-cvslog] lavc/libvpxenc: fix -auto-alt-ref option type

2016-10-21 Thread Kagami Hiiragi

ffmpeg | branch: master | Kagami Hiiragi <kag...@genshiken.org> | Thu Oct 20 
18:31:38 2016 +0300| [41da4f8cb3a7ac6888dbe6a6bbe1a573a74062ff] | committer: 
James Zern

lavc/libvpxenc: fix -auto-alt-ref option type

vp9_cx_iface actually allows values in range [0..2].
This fixes ticket #5894.

Signed-off-by: Kagami Hiiragi <kag...@genshiken.org>
Signed-off-by: James Zern <jz...@google.com>

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=41da4f8cb3a7ac6888dbe6a6bbe1a573a74062ff
---

 libavcodec/libvpxenc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 2db87f7..68f25a4 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -621,7 +621,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (ctx->flags & VP8F_AUTO_ALT_REF)
 ctx->auto_alt_ref = 1;
 if (ctx->auto_alt_ref >= 0)
-codecctl_int(avctx, VP8E_SET_ENABLEAUTOALTREF, ctx->auto_alt_ref);
+codecctl_int(avctx, VP8E_SET_ENABLEAUTOALTREF,
+ avctx->codec_id == AV_CODEC_ID_VP8 ? !!ctx->auto_alt_ref 
: ctx->auto_alt_ref);
 if (ctx->arnr_max_frames >= 0)
 codecctl_int(avctx, VP8E_SET_ARNR_MAXFRAMES,   ctx->arnr_max_frames);
 if (ctx->arnr_strength >= 0)
@@ -1025,7 +1026,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 
 #define COMMON_OPTIONS \
 { "auto-alt-ref","Enable use of alternate reference " \
- "frames (2-pass only)",   
OFFSET(auto_alt_ref),AV_OPT_TYPE_BOOL, {.i64 = -1}, -1,  1,   
VE}, \
+ "frames (2-pass only)",   
OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1},  -1,  2,   
VE}, \
 { "lag-in-frames",   "Number of frames to look ahead for " \
  "alternate reference frame selection",
OFFSET(lag_in_frames),   AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
VE}, \
 { "arnr-maxframes",  "altref noise reduction max frame count", 
OFFSET(arnr_max_frames), AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
VE}, \

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: fix -auto-alt-ref option type

2016-10-21 Thread Kagami Hiiragi

On 22/10/16 01:06, James Zern wrote:
> From: Kagami Hiiragi <kag...@genshiken.org>
> 
> vp9_cx_iface actually allows values in range [0..2].
> This fixes ticket #5894.
> 
> Signed-off-by: Kagami Hiiragi <kag...@genshiken.org>
> ---
>  libavcodec/libvpxenc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 2db87f7..68f25a4 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -621,7 +621,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (ctx->flags & VP8F_AUTO_ALT_REF)
>  ctx->auto_alt_ref = 1;
>  if (ctx->auto_alt_ref >= 0)
> -codecctl_int(avctx, VP8E_SET_ENABLEAUTOALTREF, ctx->auto_alt_ref);
> +codecctl_int(avctx, VP8E_SET_ENABLEAUTOALTREF,
> + avctx->codec_id == AV_CODEC_ID_VP8 ? 
> !!ctx->auto_alt_ref : ctx->auto_alt_ref);
>  if (ctx->arnr_max_frames >= 0)
>  codecctl_int(avctx, VP8E_SET_ARNR_MAXFRAMES,   ctx->arnr_max_frames);
>  if (ctx->arnr_strength >= 0)
> @@ -1025,7 +1026,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
> *pkt,
>  
>  #define COMMON_OPTIONS \
>  { "auto-alt-ref","Enable use of alternate reference " \
> - "frames (2-pass only)",   
> OFFSET(auto_alt_ref),AV_OPT_TYPE_BOOL, {.i64 = -1}, -1,  1,   
> VE}, \
> + "frames (2-pass only)",   
> OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1},  -1,  2,   
> VE}, \
>  { "lag-in-frames",   "Number of frames to look ahead for " \
>   "alternate reference frame selection",
> OFFSET(lag_in_frames),   AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
> VE}, \
>  { "arnr-maxframes",  "altref noise reduction max frame count", 
> OFFSET(arnr_max_frames), AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
> VE}, \
> 

Thanks, your variant is better.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: fix -auto-alt-ref option type

2016-10-21 Thread Kagami Hiiragi

On 21/10/16 06:14, James Zern wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Kagami Hiiragi <kag...@genshiken.org> wrote:
>> vp9_cx_iface actually allows values in range [0..2].
>> This fixes ticket #5894.
>>
>> Signed-off-by: Kagami Hiiragi <kag...@genshiken.org>
>> ---
>>  libavcodec/libvpxenc.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
> 
> This is all right in the sense that the library exposes the option. In
> practice the feature was never fully developed and will cause failures
> in certain hardware decoders.

vpxenc exposes it, good enough reason to allow that in ffmpeg too.

> The library will report an error (treated as a warning here) which is
> probably enough.

Passing wrong option to encoder should be treated as error in my
opinion. Without that check library will just report warning and
encoding process won't be halted.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: Re: Alternative way to achieve cancelable promise

2016-10-20 Thread Kagami Rosylight

Hi Bergi:

>You're not the only one who is unsatisfied with the current proposal :-) Also 
>have a look at

Great! I’m yet to read them but I definitely will soon to discuss more.

>Promises are result values that can be passed to multiple consumers, and not 
>every consumer should be allowed to cancel the computation. So by default, 
>promises must not be cancellable.

My current updated proposal allows cancellation only for promises created by 
`Promise.cancelable()` call. In this case, simple `return 
Promise.resolve(cancelablePromise)` will disallow cancellation for other 
consumers. But yes, this may be an opt-out rather than opt-in for APIs 
returning cancelable promises.

>I don't see the major difference between these "chain" objects and "tokens" 
>from the other proposals. Can you expand on that, please?

“Chain”s do not need to be passed manually. A chain will store cancelable 
promises and will `[@@cancel]()` them after cancellation request. Each promise 
will have its own chain which will again propagate cancellations.

>You should never pass an async function to the new Promise constructor, have a 
>look here. Fortunately, the code in your actual proposal seems more reasonable 
>here.

I agree that the constructor approach is not good and would break easily. Thus, 
my updated proposal now uses `Promise.cancelable(async (chain) => {})` rather 
than the constructor itself.

>If I understood correctly, your chain keyword could be used like await? What 
>is the difference between them?

`await` will not be automatically canceled when `chain` will:

```
cancelable function saya() {
  // This is theoretically cancelable but user somehow want it to be ‘atomic’.
  await cancelableSubWork();
  chain.throwIfCanceled();
}
```

Sincerely,
Kagami Sascha Rosylight
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[FFmpeg-devel] [PATCH] lavc/libvpxenc: fix -auto-alt-ref option type

2016-10-20 Thread Kagami Hiiragi

vp9_cx_iface actually allows values in range [0..2].
This fixes ticket #5894.

Signed-off-by: Kagami Hiiragi <kag...@genshiken.org>
---
 libavcodec/libvpxenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 2db87f7..bedaa70 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -615,6 +615,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
+if (ctx->auto_alt_ref > 1 && avctx->codec_id == AV_CODEC_ID_VP8) {
+av_log(avctx, AV_LOG_ERROR, "auto_alt_ref > 1 is forbidden for 
libvpx-vp8\n");
+return AVERROR(EINVAL);
+}
+
 //codec control failures are currently treated only as warnings
 av_log(avctx, AV_LOG_DEBUG, "vpx_codec_control\n");
 codecctl_int(avctx, VP8E_SET_CPUUSED,  ctx->cpu_used);
@@ -1025,7 +1030,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 
 #define COMMON_OPTIONS \
 { "auto-alt-ref","Enable use of alternate reference " \
- "frames (2-pass only)",   
OFFSET(auto_alt_ref),AV_OPT_TYPE_BOOL, {.i64 = -1}, -1,  1,   
VE}, \
+ "frames (2-pass only)",   
OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1},  -1,  2,   
VE}, \
 { "lag-in-frames",   "Number of frames to look ahead for " \
  "alternate reference frame selection",
OFFSET(lag_in_frames),   AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
VE}, \
 { "arnr-maxframes",  "altref noise reduction max frame count", 
OFFSET(arnr_max_frames), AV_OPT_TYPE_INT, {.i64 = -1},  -1,  INT_MAX, 
VE}, \
-- 
2.7.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

RE: Alternative way to achieve cancelable promise

2016-10-18 Thread Kagami Rosylight

Thank you for your interest in my proposal. :D

I also thought so and I posted [an older version of my proposal on 
June](https://github.com/tc39/proposal-cancelable-promises/issues/22) there. I 
got this answer:

>This is a separate proposal, and not an issue with the proposal being 
>developed in this repo. So, I'll close this issue. You're welcome to continue 
>using it as a discussion thread for your proposal, but in general there are 
>better places to do that, such as es-discuss or your own GitHub repo you 
>created for your proposal.

Thus I’m posting this here separately to gain attention and discuss.

From: Marky Mark<mailto:m...@heyimmark.com>
Sent: Wednesday, October 19, 2016 11:20 AM
To: Kagami Rosylight<mailto:sascha...@outlook.com>; 
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Alternative way to achieve cancelable promise

I must admit that I do like this approach, however I'm not too familiar with 
the proposed spec to definitively comment on this. Have you tried proposing 
this in the https://github.com/tc39/proposal-cancelable-promises repository? 
That may be a better avenue for your suggestions.

On Sat, Oct 15, 2016 at 3:15 AM Kagami Rosylight 
<sascha...@outlook.com<mailto:sascha...@outlook.com>> wrote:
I want to find a way to replace cancellation token in the current [stage 1 
cancelable promise 
proposal](https://github.com/tc39/proposal-cancelable-promises) with an 
alternative way which does not require passing an additional parameter.

Here is a short representation of [my current 
thought](https://github.com/SaschaNaz/cancelable):

```ts
// A cancelable object supports new `Symbol.cancel`.
// `object[Symbol.cancel]()` will cancel any tasks related to the object.
interface Cancelable {
  [@@cancel](): void;
}

interface Promise extends Cancelable {}
```

```js
// Here, a new `chain` object from promise constructor callback will
// help chaining cancelable tasks and provide cancellation related
// helper functions.

function foo() {
  return new Promise(async (resolve, reject, chain) => {
await nonCancelableSubWork1();
chain.throwIfCanceled(); // This line will throw `Cancel` object if the 
promise got a cancellation request
await nonCancelableSubWork2();
resolve();
 });
}

function bar() {
  return new Promise(async (resolve, reject, chain) => {
 // This `chain()` call will register foo() to the cancellation chain of a 
promise instance
 // and will propagate cancellation to the chained tasks.
 // The chain can receive any object that supports `Symbol.cancel`.
 await chain(foo());
 await chain(baz());
 });
}

const promise =  bar();
promise.cancel(); // This will cancel `bar` call and the cancellation will 
propagate to `foo` and `baz`
```

And with some syntax sugar for readability:

```js
cancelable function foo() {
  // `chain` is a keyword inside cancelable function blocks
  await nonCancelableSubWork1();
  chain.throwIfCanceled(); // similar form like `new.target`
  await nonCancelableSubWork2();
}

cancelable function bar() {
  chain foo();
  chain baz();
}

const promise = bar();
promise.cancel();

cancelable function baz() {
  try {
chain baw();
  }
  else {
// try-else block will catch cancellation, as the current existing proposal 
does
  }
}
```

I think this will achieve easier and more readable flow of cancelable tasks, 
what do you think?
___
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--

mark

Sent while riding a hoverboard...
heyimmark.com<http://heyimmark.com> :)

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Alternative way to achieve cancelable promise

2016-10-15 Thread Kagami Rosylight

I want to find a way to replace cancellation token in the current [stage 1 
cancelable promise 
proposal](https://github.com/tc39/proposal-cancelable-promises) with an 
alternative way which does not require passing an additional parameter.

Here is a short representation of [my current 
thought](https://github.com/SaschaNaz/cancelable):

```ts
// A cancelable object supports new `Symbol.cancel`.
// `object[Symbol.cancel]()` will cancel any tasks related to the object.
interface Cancelable {
  [@@cancel](): void;
}

interface Promise extends Cancelable {}
```

```js
// Here, a new `chain` object from promise constructor callback will
// help chaining cancelable tasks and provide cancellation related
// helper functions.

function foo() {
  return new Promise(async (resolve, reject, chain) => {
await nonCancelableSubWork1();
chain.throwIfCanceled(); // This line will throw `Cancel` object if the 
promise got a cancellation request
await nonCancelableSubWork2();
resolve();
 });
}

function bar() {
  return new Promise(async (resolve, reject, chain) => {
 // This `chain()` call will register foo() to the cancellation chain of a 
promise instance
 // and will propagate cancellation to the chained tasks.
 // The chain can receive any object that supports `Symbol.cancel`.
 await chain(foo());
 await chain(baz());
 });
}

const promise =  bar();
promise.cancel(); // This will cancel `bar` call and the cancellation will 
propagate to `foo` and `baz`
```

And with some syntax sugar for readability:

```js
cancelable function foo() {
  // `chain` is a keyword inside cancelable function blocks
  await nonCancelableSubWork1();
  chain.throwIfCanceled(); // similar form like `new.target`
  await nonCancelableSubWork2();
}

cancelable function bar() {
  chain foo();
  chain baz();
}

const promise = bar();
promise.cancel();

cancelable function baz() {
  try {
chain baw();
  }
  else {
// try-else block will catch cancellation, as the current existing proposal 
does
  }
}
```

I think this will achieve easier and more readable flow of cancelable tasks, 
what do you think?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight

>From a technical point of view, using ![ instead of ?.[ may work only if you 
>forbid a line terminator before the !

I tried this on [TS 
Playground](http://www.typescriptlang.org/play/#src=var%20a%20%3D%20%7B%7D%3B%0D%0A%0D%0Aa!%5B3%5D%3B%0D%0Aa%0D%0A!%5B3%5D%3B)
 and it interestingly changes behavior when there is a line break before `!`.

```js
var a = {};

a![3]; // works as a[3]
a
![3]; // preserves original behavior
```

>but many languages (e.g. Swift, Kotlin, and I think TypeScript 2.0) use it in 
>the inverse direction: non-null assertion for nullable types.

Right. :/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight

>Why is this needed? Why are people trying to get the property of an object 
>which is null?

I will appreciate null propagation when a function receives an “option bag”

```js
function someFunction(options) {
  if(options?.foo) {
doSomething();
  };
}

someFunction();
someFunction({ foo: true });
```

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight


>IIRC the proposed syntax for computed properties was x?.[y],

Yes you’re right, sorry :/

IMO it still seems the syntax problem is the main reason why this proposal has 
stalled. If not, what is the problem here? I’m curious why this proposal is not 
even listed in stage 0 proposal list.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight


>The token ?. works fine

I think more than half of this thread is about syntactic ambiguity, regardless 
of whether the ambiguity is real or not. For example, from [an earlier post of 
this 
thread](https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44):

>But what should be done with cases like obj?[1]?[2]:[3].

A formatter may help this and make it `obj?[1] ? [2] : [3]` or `obj ? [1]?[2] : 
[3]` depending on operator precedence, but shouldn’t it be more clear? 
`obj![1]?[2]:[3]` will not be confused with ternary operator.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight


Or `!.`, which unfortunately is now being used by TypeScript?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Class syntax enhancements

2016-10-08 Thread Kagami Rosylight


You’re right, my `partial` function does not support multiple inheritance and 
the input class should not have its own prototype chain. I think partial class 
and multiple inheritance are two different issues, however, as the former can 
work without the latter and vice versa.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-09-30 Thread Kagami Rosylight

Is the only problem here is the parser problem with `obj.prop?.2:.1`? Then how 
about `??. ` instead of `?.`? 

>Once upon a time, there was a fascinating proposal on this subject:

Why are you posting twice? :/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Class syntax enhancements

2016-09-26 Thread Kagami Rosylight

I’m not sure it’s okay to reply on this very old thread, but if I’m 
understanding correctly the desugared code can be fairly short with new 
Object.getOwnPropertyDescriptors:

```js
function partial(base, extension) {
  extension.prototype.__proto__ = base.prototype.__proto__; // to enable 
'super' reference
  const descriptors = Object.getOwnPropertyDescriptors(extension.prototype);
  delete descriptors.constructor; // must not override constructor
  Object.defineProperties(base.prototype, descriptors);
  
  return base;
}
```

```
class A {
  foo() {
    return "foo"
 }
}

class B extends A {
}

partial(B, class {
  foobar() {
    return `${super.foo()}bar`;
  }
})

output.value = new B().foobar(); // will be “foobar;
```

This sample currently only works on Firefox 50+. https://jsfiddle.net/v8bbvavv/

Sent from Mail for Windows 10

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[TYPO3-english] Header Introduction Package

2012-11-08 Thread Kagami

A few days ago i started working Typo3.
Many things are clear. But there is still a big layout problem.
I like to change the lay-out of the introduction page. First of all The
HEADER.
I tried changing images, jpg en gif files. Nothing changed after this.
Is here someone who can help me to start changing the images and colors of
the Introduction Packages from Type3?
Many tanks
Peter




--
View this message in context: 
http://typo3.3.n7.nabble.com/Header-Introduction-Package-tp234199.html
Sent from the TYPO3 English mailing list archive at Nabble.com.
___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english

Re: [TYPO3-english] Header Introduction Package

2012-11-08 Thread Kagami

Cache is clearedThe files i've chanched
are:Fileadmin/default/images/bg_header.jpgFileadmin/default/images/bg_firstLevel.gifFileadmin/default/template/css/stylesheet.cssFileadmin/default/template/css/frontpage.cssRegards,Peter



--
View this message in context: 
http://typo3.3.n7.nabble.com/Header-Introduction-Package-tp234200p234210.html
Sent from the TYPO3 English mailing list archive at Nabble.com.
___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english

Re: [TYPO3-english] Header Introduction Package

2012-11-08 Thread Kagami

Cache is cleared
The files i've chanched are:
Fileadmin/default/images/bg_header.jpg
Fileadmin/default/images/bg_firstLevel.gif
Fileadmin/default/template/css/stylesheet.css
Fileadmin/default/template/css/frontpage.css

Regards,Peter
 





--
View this message in context: 
http://typo3.3.n7.nabble.com/Header-Introduction-Package-tp234200p234212.html
Sent from the TYPO3 English mailing list archive at Nabble.com.
___
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english

Re: squeeze после очередного обновления поломалось KDE

2010-06-14 Thread Kagami


14.06.2010 00:24, vanessa пишет:

Я скоро буду бояться обновлять систему. Один раз оно (KDE) уже
поломалось, когда вместо kde-minimal стал kde-plasma-desktop. сегодня в
очередной раз сделал aptitude update  aptitude safe-upgrade после чего
KDE перестало работать. Оно вроде запускается но после исчезновения
картинки запуска экран белеет, проигрывается стартовая мелодия и все.
так белый экран и остается

обновились кроме всего прочего kde-plasma-desktop и kde-workspace-data

Как его починит ?


Смотрите баг #585751.

--
WBR, Alexander.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c15e83e.7010...@crossplatform.ru

Re: Пожалуйста, посет ите опросник Debian

2010-06-14 Thread Kagami


14.06.2010 19:40, Mark Goldshtein пишет:

http://tinyurl.com/3y33ska


Готово


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c168d0d.6080...@crossplatform.ru

Re: Переключение CTRL+ALT+F1

2010-06-08 Thread Kagami


07.06.2010 13:40, Artem Shrub пишет:

Здравствуйте!

После обновления с lenny до squeezy перестало работать переключение в
виртуальную консоль :(. Как это исправить?


У меня где-то полгода назад при нажатии Ctrl+Alt+F1 в иксах переключения 
в консоль не происходило, вместо этого просто замирало изображение на 
экране. Если вернуться на седьмую виртуальную консоль, то все снова 
начинало отрисовываться. Тогда исправил этот баг отключением KMS для 
модуля видеокарты (стоит intel 945GM). Но через пару месяцев очередным 
обновлением вроде вылечилось.


--
WBR, Alexander.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0e8c00.1030...@crossplatform.ru

Re: Переключение CTRL +ALT+F1

2010-06-08 Thread Kagami


08.06.2010 22:41, Andrey Rahmatullin пишет:

Надо было vesafb отключить.


Вот до этого я не догадался. Спасибо за совет.

--
WBR, Alexander.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0e92f4.20...@crossplatform.ru

Проблемы со splashy на eeepc 901

2010-03-28 Thread Kagami

Всем привет.

После очередного обновления сквизи перестало нормально работать splashy.
При загрузке экран выглядит странно - изображение отрисовывается в
сжатом виде и только не левой половине экрана, а еще искажены цвета [0].
Причем фреймбуффер работает нормально, до запуска splashy и после него
консоль рисуется на весь экран и с цветами все впрорядке. В командной
строке были такие параметры: vga=788 splash quiet.

Попробовал другие режимы. vga=791 больше разрешения экрана (1024х600),
если его включить, изображение сильно искажено даже в консоли. Пробовал
поставить vga=789, но стало только хуже - изображение отрисовывается на
одной четверти экрана. Если поставить vga=771, то изображение выводится
на весь экран, но хромают цвета.

Так как в сквизи сейчас ядро 2.6.32, которое поддерживает kms,
попробовал передать ядру параметр i915.modeset=1. Получил родное
разрешение в консоли, но проблему это не решило, изображение все равно
выводилось только на части экрана.

Следующим моим шагом было попробовать uvesafb, но опять ничего не
получилось. Затем я пробовал переставить splashy, выбирать другую тему,
но тоже без результата. Не помогла даже перекомпиляция splashy. Больше
идей у меня нет...

Никто с таким не сталкивался? В чем может быть причина такого поведения?

[0] http://img6.glowfoto.com/images/2010/03/27-0901422591L.jpg

С уважением,
Александр.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4baf1b27.2070...@crossplatform.ru

Re: eeepc 1005 PE

2010-03-21 Thread Kagami


Alexey Pechnikov пишет:

Спасибо, со временем работы ясно. Если найдете возможным отписаться
о результатах установки на сабж дебиана, уверен, будет интересно не 
только мне.
Про установку и настройку дебиана на различные модели eeepc есть 
соответствующая страница в вики [0]. Про различные модели можно 
посмотреть там же [1],


[0] http://wiki.debian.org/DebianEeePC
[1] http://wiki.debian.org/DebianEeePC/Models


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba68203.4010...@crossplatform.ru

Bug#551906: [teeworlds] no sounds

2010-02-28 Thread Kagami


Hello.

Looks like you made diff teeworlds_new teeworlds_old, so the correct 
value for BASE_PATH is /usr/share/games/teeworlds/data/, not 
/usr/share/games/teeworlds/.


--
WBR, Alexander




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571690: subtitlecomposer: russian translation

2010-02-27 Thread Kagami


Package: subtitlecomposer
Version: 0.5.3-3
Severity: wishlist
Tags: l10n

Please add russian translation from official svn repository [0] or [1]

[0] 
http://subcomposer.svn.sourceforge.net/viewvc/subcomposer?view=revrevision=44

[1] http://sourceforge.net/support/tracker.php?aid=2953734

--
WBR, Alexander

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages subtitlecomposer depends on:
ii  kdebase-runtime  4:4.3.4-2   runtime components from the 
offici
ii  kdelibs5 4:4.3.4-1   core libraries for all KDE 
4 appli

ii  libc62.10.2-2GNU C Library: Shared libraries
ii  libgcc1  1:4.4.2-9   GCC support library
ii  libglib2.0-0 2.22.4-1The GLib library of C routines
ii  libgstreamer-plugins-base0.1 0.10.26-1   GStreamer libraries from 
the base
ii  libgstreamer0.10-0   0.10.26-1   Core GStreamer libraries 
and eleme

ii  libphonon4   4:4.5.3-4   Qt 4 Phonon module
ii  libqtcore4   4:4.5.3-4   Qt 4 core module
ii  libqtgui44:4.5.3-4   Qt 4 GUI module
ii  libstdc++6   4.4.2-9 The GNU Standard C++ Library v3
ii  libxcb1  1.5-2   X C Binding
ii  libxine1 1.1.17-1+b1 the xine video/media player 
librar

ii  phonon   4:4.5.3-4   Qt 4 Phonon module metapackage

subtitlecomposer recommends no packages.

Versions of packages subtitlecomposer suggests:
ii  mplayer 1:1.0.rc2svn20091220-0.0 The Ultimate Movie Player 
For Linu


-- no debconf information




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571690: subtitlecomposer: russian translation

2010-02-27 Thread Kagami

Sorry, I made two bug by mistake, this and 571687. Please, close 
unnecessary one,





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[Pkg-kde-extras] Bug#571690: subtitlecomposer: russian translation

2010-02-27 Thread Kagami

Sorry, I made two bug by mistake, this and 571687. Please, close 
unnecessary one,





___
pkg-kde-extras mailing list
pkg-kde-extras@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-extras

Re: Перевод Synaptic 0.63.1

2010-02-23 Thread Kagami


Yuri Kozlov пишет:
  #: ../common/rconfiguration.cc:147

#, c-format
msgid ERROR: could not create state directory %s
msgstr ОШИБКА: невозможно создать каталог состяния %s

состояния



Спасибо, не заметил очепятку в старом переводе. Поправил.

--
WBR, Alexander


--
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b83f2a7.7020...@crossplatform.ru

Re: А где CodeBloks?

2010-02-22 Thread Kagami


Сергей Крайко пишет:

On Mon, 22 Feb 2010 14:49:21 +0300
Ekimov Alexandr toeki...@gmail.com wrote:


В сообщении от Понедельник 22 февраля 2010 14:31:18 автор Сергей
Крайко написал:

Поискал в репах и не нашёл CodeBloks. В ubuntu есть а в дебиане что
нет?


Такой программы не существует. Есть ,правда, Code::Blocks.


Ну Code::Blocks я тоже не нашёл.




Советую посмотреть на http://apt.jenslody.de/

--
WBR, Александр.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b82780f.5020...@crossplatform.ru

Re: Перевод Synaptic 0.63.1

2010-02-20 Thread Kagami

Yuri Kozlov пишет:

В Thu, 18 Feb 2010 22:39:36 +0300
Kagami kag...@crossplatform.ru пишет:

Привет всем.

Я решил поправить перевод для Synaptic 0.63.1 (в текущий момент
переведены не все строки). Когда я закончу перевод, куда его лучше
разместить? Сюда для проверки и обсуждения или создать баг в BTS?

Попробуйте списаться с предыдущими переводчиками.
Причём Святослав, похоже, непосредственно участвует в проекте.

Sviatoslav Sviridov (svdataltlinux.ru) (Russian)
Vitaly Lipatov (lavataltlinux.ru) (Russian)

Я напишу им, хотя и слегка сомневаюсь в результате - судя по po-файлу,
Святослав переводил его в 2003 году, а Виталий - в 2005.

P.S. Я еще вчера отправил в этот список рассылки письмо с вложенным
переводом и diff-ом по сравнению с тем, что сейчас находится в пакете.
Однако оно не сюда не попало. Суммарный размер вложения составил ~150
Кб. В этом списке рассылки есть какое-то ограничение на размер вложений?

--
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7fac39.3080...@crossplatform.ru

Re: Перевод Synaptic 0.63.1

2010-02-20 Thread Kagami


Всем привет!

Во вложении мой перевод интерфейса Synaptic 0.63.1 и diff между ним и 
тем что было в пакете. Сжал gzip'ом до 30 Кб, надеюсь что теперь оно 
попадет в список рассылки. Хотелось что бы его проверили перед тем как 
отправлять его сопровождающему пакета.


--
WBR, Александр.


ru.po.tar.gz
Description: GNU Zip compressed data

Перевод Synaptic 0.63.1

2010-02-18 Thread Kagami


Привет всем.

Я решил поправить перевод для Synaptic 0.63.1 (в текущий момент 
переведены не все строки). Когда я закончу перевод, куда его лучше 
разместить? Сюда для проверки и обсуждения или создать баг в BTS?


--
WBR, Alexander.


--
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7d9778.4040...@crossplatform.ru

Re: photoshop cs2 shortcuts

2010-02-16 Thread Kagami


Alexey Boyko пишет:

Sergey Korobitsin пишет:

Хм, у нас разные sid-ы? В моем 1.1.15.

  http://packages.debian.org/sid/wine
  Написано 1.0.1-2. Не?


http://packages.debian.org/sid/wine-unstable



Внесу свои 5 копеек - http://www.lamaresh.net/



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7afc48.3010...@crossplatform.ru

Re: KVIrc 4:4.0.0~svn3900+rc2-1: Please update the PO translation for the package kvirc

2010-01-30 Thread Kagami


Kai Wasserbäch пишет:

Dear Russian language team,
I'm one of the maintainers of KVIrc in Debian and would like to ask you to help
get the translation of KVIrc in shape before the release of Squeeze, if that is
possible.

You can find the current PO files at [0]. Please file any translation as a
wishlist bug against the KVIrc package in Debian.

Thank you in advance for your help!

Kind regards,
Kai Wasserbäch


[0] http://dev.carbon-project.org/debian/kvirc/translations/ru.html



I'm not in Russian language team, but right now I'm working on large 
russian translation update for KVIrc. In few days there are will be a 
large commit in KVIrc svn repository [0], mainly kvirc_ru.po and 
options_ru.po.


WBR, Alexander.

[0] https://svn.kvirc.de/svn/trunk/kvirc


--
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: nvidia на 2.6.32-trunk

2010-01-25 Thread Kagami


Andrey Nikitin пишет:

Привет.

У одного меня nvidia на 2.6.32-trunk не собирается?

% sudo m-a -t a-i nvidia
...

NVIDIA: calling KBUILD...
make CC=gcc-4.3 -C /lib/modules/2.6.32-trunk-686-bigmem/build 
SUBDIRS=/usr/src/modules/nvidia-kernel modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.32-trunk-686-bigmem'
  Building modules, stage 2.
  MODPOST 0 modules
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-trunk-686-bigmem'
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[2]: *** [module] Ошибка 1
make[2]: Leaving directory `/usr/src/modules/nvidia-kernel'
make[1]: *** [build-stamp] Ошибка 2
make[1]: Leaving directory `/usr/src/modules/nvidia-kernel'
make: *** [kdist_image] Ошибка 2
BUILD FAILED!
See 
/var/cache/modass/nvidia-kernel-source.buildlog.2.6.32-trunk-686-bigmem.1264411767
 for details.




На 2.6.32-trunk-686 все собралось. Исходники дров брал из сида.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: nvidia на 2.6.32-trunk

2010-01-25 Thread Kagami


Andrey Nikitin пишет:

В Mon, 25 Jan 2010 13:02:41 +0300
Kagami kag...@crossplatform.ru пишет:


На 2.6.32-trunk-686 все собралось. Исходники дров брал из сида.

Кстати, m-a можно указать что нужно брать с другой версии дистра (аля
apt-get -t dist)?
Я, в таких случаях, делаю бэкпорт, руками устанавливаю
module-source_X.deb и только потом m-a a-i module.




Судя по ману - нет, надо руками устанавливать нужный пакет с сорцами.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Кракозябли в титрах S MPlayer

2010-01-02 Thread Kagami


James Brown пишет:

Запускаю фильм из каталога (включающего один файл .avi и другой .srt)
под SMPlayer  0.6.1 (SVN r1304) из основного дистра ленни - в субтитрах
вместо русских букв кракозябли. Как исправить?




Ctrl+P - Субтитры - Кодировка субтитров по умолчанию.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[FreeBSD-users-jp 89421] Re: 6.0R でブロックサイズ 65536 の UFS1 を正しく扱えない

2006-04-09 Thread KAGAMI Hiromichi

こんにちは、鏡です。

From: [EMAIL PROTECTED]
Subject: [FreeBSD-users-jp 89414] 6.0R でブロックサイズ 65536 の UFS1 を正しく扱えない
Date: Sat, 08 Apr 2006 16:46:22 +0900

 症状
 (1) 6.0Rでブロックサイズ65536のUFS1を作ると、fsckでエラーが出ます。
 (2) 4.11Rで書き込んで、6.0Rでdfすると使用量が変化していません。
 (3) 4.11Rで作ったUFS1と、6.0Rで作ったUFS1で挙動が異なります。
  ブロックサイズ16384では問題ありません。

古い話で恐縮ですが、FreeBSD-4系列初期の頃、大量のストリームデーターを 
64K 単位でバッファリングして書き込むため 65536バイトブロックを使用した
ところ、動作が不安定となり、仕方がないので 32768を使った記憶があります。

4.11R で良くなり 6系列で宜しくないのは違う原因なのかもしれませんが、最
大 32768で運用する方が安全なのかも知れません。32768 と 65536 で速度に
関して特に有意な差は感じられませんでした。

--
鏡 弘道
[EMAIL PROTECTED]

[Lesstif-discuss] Do away with everything you are indebted for without paying an other cent

2006-02-26 Thread Kagami

Heya Renzo,

I was chatting to Pat yesterday about all the debt I've piled up in the
past mnth, it's sucks. I'm owe close to 22 k, and that's just on my creid
card.

Luckly Krista, showed me this company, www.plebetientayakefew.com/jk8/, and
they assisted me take all the stress away. They basically take over all the
hard work and all you need to do is sit back an enjoy.

Hope this helps,
Kagami



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Lesstif-discuss mailing list
Lesstif-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lesstif-discuss

91 matches

Mail list logo