Android dynamic rendering not updating

I am using react-native-svg-charts and I am seeing new behavior since updating this library. Suddenly when rendering children of the overall SVG component dynamically, they do not update regularly on Android though they do have predictable results.
For instance, with new props they will redraw, but if they are replaced with null or another invisible element with the same key they will not.  The only way I've been able to get an update is to force it with a dynamic key on the container of the entire SVG element which causes a bad flash to occur when redrawing.
Versions:

react-native: 0.57.4
react: 16.6.0-alpha.8af6728
react-native-svg: ^8.0.8

For the current chart implementation of the SVG component I'm using refer here: https://github.com/alburdette619/react-native-svg-charts/blob/dev/src/chart/chart-grouped.js#L105
Then I am using that and attempting to dynamically render children using standard JSX syntax:
<LineChart...>
  {condition ? <Child/> : null}
</LineChart>

I've tried setting keys on the Child, setting dynamic keys to force an update, but the only thing that works is setting a dynamic key on LineChart which is the overall container for the SVG element.

@msand sorry to tag you, but I cannot make this happen.  I came back to it trying to again set some dynamic keys.  I am seeing that the children are in the tree properly every time, but sometimes they stay when they shouldn't and don't show when they should.  Also having weird issues like this on paths where they just disappear.  I think I'm treading into some other issues, but I don't see a workaround.  Please help!

Can you try this change? https://github.com/JesperLekland/react-native-svg-charts/pull/280/files

Sorry, been busy, hopefully we will get to this today or tomorrow.  Thanks!

@msand The change https://github.com/react-native-community/react-native-svg/issues/853#issuecomment-445502539 didn't work.
<LineChart...  key={chartKey}>
  {condition ? <Child key={childKey}/> : null}
</LineChart>

If I change childKey also the child won't re-render. If I change chartKey will re-render all the graph but this makes the graph blinks.


Video starts with black screen and no sound

I'm submitting a ...

[x ] bug report
[ ] feature request
[ ] support request

General infomration
I can't watching Netflix videos.
Prerequisites

[ x] Are you running the latest version?

Description
After select any video i have black screen and no sound.
[Description of the bug or feature]
Steps to Reproduce

[First Step] Play any video from Netflix
[Second Step] Wait and look

Expected behavior: [What you expected to happen]
I want watching video from Netflix.
Actual behavior: [What actually happened]
As up.
Context (Environment)
Android 7.1.2
Tv Box t95z plus.
Installation

[ ] I installed the plugin via zip from the Releases page
[x ] I´m using the Netflix Repo
[ ] I´m using a different source (Please tell which)

Operating System

[ ] Linux (x86/x64)
[ ] OSX (x86/x64)
[ ] Windows (x86/x64)
[ ] Linux (ARM)
[ x] Android

Additional informatin on the environment
[Descripe your environment a bit more detailed, are you using LibreElec f.e.]
Debug log
https://m.sendspace.com/file/5u4e4v
Other information
Earlier on previous version Kodi 18 from April 2018 this addon works correctly. After update Kodi 18 to version from 09.06.2018, i can't watching.

pls. use pastebin or something where one can download log without registering

https://pastebin.com/YdBTmSA3
Here :)

pls:

navigate to a stream
adb logcat -c
play the stream some seconds
adb logcat -d | pastebinit

https://pastebin.com/n3NJ1v53
and short movie https://drive.google.com/open?id=1OE6UQbf9gRan6_uNlJGZZu5zu_xc-wD-

The issue is "unsufficient output protection" which could be caused by the widevine transfer protocol.
Pls. try branch 394 : https://github.com/asciidisco/plugin.video.netflix/archive/394.zip (install from zip inside kodi)

Not works, i have loading for few seconds and later exit to list of movies.
https://pastebin.com/bcEFsWu8 logcat

@n152 if you don't trust the support provided hiere (you may know that peak3d is the author of inputstream.adaptive and the DRM part in kodi) we cannot help anymore.
I suggest that we close the issue.

I trust you, but I see that addon works perftect on previous version of Kodi, so maybe this info will be usefull to fix this error :) .

@n152 and now? What do you suggest to do?
If you want to solve it your way, I'm fine with it because I don't have to spend hours on your 20$ box issues (which seem to be not existant on other devices),
You could try your luck in stackoverflow or whatever. Don't try kodi trac / forum because you'll be routed to me again.

Ok, if you haven't any more suggestions how can I help you to fix it I want said you thanks for any help and interest with my problem. I hope so it will be ok in future...

Could be that the language barrier is the issue here, but we just started investigating.
I read your prev. post that you would like to have other support.

Deinstall netflix including your userdata (you will be asked during deinstallation)
Install the version provided above again (the 394.zip file)
Log in again, and if it fails pls. provide a complete kodi log (debug enabled)

I was trying 3 times play video and no success.
Debug Log https://pastebin.com/jytXP2Ki

Last check for tonight:
Pls. restart kodi, and provide the kodi log after trying to play 1(!) stream.

https://pastebin.com/SktdBSYj

Ok, unfortunately the old key xchange handling is not worling with your device / ESN so we have to continue investigating with the normal 0.13.8 version.
To prepare your device you should again deinstall the 394.zip version with user_data because there are still keys in userdata folder from old  login procedure.
I'll try to find a widevine L3 device for reproduction. All my L1 devices work without issues.
Could take some days, until then you could report the issue in the german kodinerds.net forum, they normally respond to english, too.

Inactive

This worked for me:
Go into Netflix addon-settings and select inputstream options
Tick "override HDCP Status" and "ignore resolution" - one of that options solved the problem for me. I guess its the resolution thing, as my TV said "not supported signal"


Add \abbr{}{} command

Hi,
I tried to create an \abbr command ( #1 ) . It uses a glossary with a link to navigate between the glossary and the abbreviation.
I made some changes in the Makefile and I removed some trailing spaces.

@Karnaj do you have some suggestions to improve this?

I was afraid that using the command twice for the same abbreviation would define the same word twice, but maybe it was with old version of LaTeX. On  the other hand, I'm not very fond of the result (spaces are too large):

... And I would prefer a version with ulem if possible. Not that I don't like tikz, but LaTeX will not be able to perform hyphenation on this, resulting in lines that will be sometimes too long.

And is it possible to have one glossary by chapter ?

I was afraid that using the command twice for the same abbreviation would define the same word twice

To me, its the normal behaviour, and we obtain links for all pages where it’s used.

To me, its the normal behaviour, and we obtain links for all pages where it’s used.

Me as well, I had this issue 3 years ago ^^

And is it possible to have one glossary by chapter (could be nice)?

Indeed :)

@pierre-24 Ok for ulem and spaces are fixed.

And is it possible to have one glossary by chapter (could be nice)?
I don't think it's a good idea and I think the reader could be lost. An abbreviation will have the same signification in the whole text, so at each chapter we will see a glossary with different entries or sometimes, the same as previous ones.

I don't think it's a good idea and I think the reader could be lost. An abbreviation will have the same signification in the whole text, so at each chapter we will see a glossary with different entries or sometimes, the same as previous ones.

Indeed...
A "problem" stays: wa can’t have abbreviation with accent. I don’t believe we have accentuated abbreviation, but it could be problematic.

A "problem" stays: wa can’t have abbreviation with accent. I don’t believe we have accentuated abbreviation, but it could be problematic.

Sadly, it is a difficult problem to fix on latex side (because the first word is used to create a command). Best thing we can do is to accept it and add a warning in the documentation.

Good to me. As I said, we surely don't have accentuated abbreviations.

Or create a new package glossaries? :D
The other solution is:
\abbr{word without accent}{word}{def}...

\abbr{word without accent}{word}{def}...

Will not work well: you still need to use the "word without accent" in \gls{}. And still, according to the manual, you need to take extra care for the accentuated letters in the name=thing part.

Or create a new package glossaries? :D

There seems to be xindy to create indexes.  But it only fix some sorting issues, not the label one.

Ok. So I'll change the doc.

There seems to be xindy to create indexes. But it only fix some sorting issues, not the label one.

I don’t know if it’s work, but i found that.

Two things to do:

change documentation,
use a single \AtEndDocument.

Two things to do:

change documentation,
use a single \AtEndDocument.

Done (and I correct some mistakes)

Good to me, sorry for the long time ;)


[5.0.0-rc1] repeated ValueAnimation effect in long lists

What was tried:
Increasing the text size inside a textview by utilising ValueAnimation and decreasing it again. The former happens when expanding an expandableItem the latter when collapsing it again.
What went wrong
In a long list of items the effect of an increased text size was repeated by non expanded items. This is most likely an effect caused by the recycling of views. (My first guess)
What was done
In createViewBinder() the current textSize is stored within the ViewBinderClass of this item. It is used as a refference to increase from or decrease to respectively. To start the animations the methods expandView() and collapseView() of the ViewHolder were overriden.
Question
How can I reset the text size of items when they are recycled. Is there a method to override?

@ketain, yes Adapter has onViewRecycled() to override, but you must call super().

Thanks for the fast answer :)
I didn't say so before but: This really is a great library! :)
Nahh I am bad at this but please feel complimented. 👍

Thank you @ketain!


Enable Sourcegraph

I want to use Sourcegraph for beehive-netctrl code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/kandoo/beehive-netctrl. (It should only take 30 seconds.)
Thank you!

Done. :-)
On Tue, Jul 14, 2015 at 8:32 AM Waqas Ahmed<EMAIL_ADDRESS>wrote:

I want to use Sourcegraph https://sourcegraph.com for beehive-netctrl
code search, browsing, and usage examples. Can an admin enable Sourcegraph
for this repository? Just go to
https://sourcegraph.com/github.com/kandoo/beehive-netctrl. (It should
only take 30 seconds.)
Thank you!
—
Reply to this email directly or view it on GitHub
https://github.com/kandoo/beehive-netctrl/issues/2.


fix: support configDir for other compilerOptions fields

This PR adds support for the "${configDir}" variable interpolation for all the fields in "compilerOptions" object as listed in the original issue

Sorry I didn't open an issue, it was faster to make a fix than a repro example :)

No problem, thanks for the PR!
Can you add a test or update the existing one for confibDir to include these properties?

No problem, thanks for the PR!
Can you add a test or update the existing one for configDir to include these properties?

Added test cases. Also, I fixed a bug when "declarationDir" was missed in generated "excludes", now that matches behaviour of TS :)

Ah nice catch! Thanks for the PR 🙌

:tada: This PR is included in version 4.8.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Improvement] Plugin Cookie Jar API

hi
Following on discussion on Twitter
https://twitter.com/GetInsomnia/status/926717993710772224
As discussed, it should be possible for a plugin to unset, if not any cookie, at least the cookies that were created by the plugin.
In my particular case, I need to add a cookie named XDEBUG_SESSION to enable Xdebug...
But need to remove the cookie to disable it Xdebug.
More on Xdebug here: https://xdebug.org/
I did see this note at the bottom of  app/plugins/context/request.js:
// NOTE: For these to make sense, we'd need to account for cookies in the jar as well
// addCookie (name: string, value: string): void {}
// getCookie (name: string): string | null {}
// removeCookie (name: string): void {}

So these methods have not been implemented yet.
Also tried to pass and empty string or null as value, in the hope these would reset the cookie, but that isn't the case.
Guessing the removeCookie () would be the best solution...
But accepting null as value to setCookie() would be perfectly fine for me.
Thanks in advance,
@dgoosens

Quick thought @dgoosens...
addCookie() doesn't actually save the cookie in the jar. It just tells the current request to send it. So, simply not calling addCookie() the next time should cause it to not be sent.
Does this flow not work for you, or are you somehow getting back a set-cookie header that's adding the cookie to the jar?
... Either way, I think modifying the cookies in the jar should be a supported feature of the plugin API.

hi @gschier
Not using addCookie() but setCookie() as it is described in the API's documentation
(section Request Hook API https://insomnia.rest/documentation/plugins/#request-hook-api)

Sorry. setCookie is what I meant to say.

OMG...
Why didn't I think of that !!
Just tested and that seems to work...
Nice !
Thanks

Haha. Sometimes the simple things are easy to miss. Happens to me all the time 😄


log output from initContainers is not shown in console or web UI - feature

I have a Pod with an initContainer. Logs from the Pod are shown in Tilt, but initContainer logs are not displayed. In my case the initContainer is restoring a database. Without the log output it appears the Pod is hung. I have to check it with k9s
Is it possible to show initContainer logs in tilt?

Thanks @bkcfsi:  We have this already logged in #2292. Do you mind 👍 that issue there? We have a few thumbs there already and hope to prioritize work at some point.
I’ll close this one out so that we don’t have duplicates.


Grab bag of fixes for small test issues

Fix a rare overflow issue in the integer square root test.
Add support for running HashTreeCollections on systems where Int is 32 bits wide (like watchOS).
Reduce the test workload for such systems, as they tend to be a bit slower than 64 bit devices -- we don't really want the test suite to take hours on watchOS, for example.

Checklist

[X] I've read the Contribution Guidelines
[X] My contributions are licensed under the Swift license.
[X] I've followed the coding style of the rest of the project.
[X] I've added tests covering all new code paths my change adds to the project (if appropriate).
[ ] I've added benchmarks covering new functionality (if appropriate).
[X] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
[ ] I've updated the documentation if necessary.

@swift-ci test

Same unrelated issue as with #285. I think one of the executors might be broken. 🤔
groovy.lang.MissingPropertyException: No such property: download for class: java.lang.String
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Setting status of a5fda7c368e06561fba87dd33c47443e879dd6da to FAILURE with url https://ci.swift.org/job/pr-swift-collections-macos/166/ and message: 'Failed
 '
Using context: Swift Test macOS Platform
Finished: FAILURE

@swift-ci test macOS platform

@swift-ci test macOS platform

Well, macOS testing seems down currently. Merging on the Linux build results.


RLIMIT_NOFILE is cached in the go runtime, and RLIMIT_NOFILE in the cache is restored for the child process before exec.
Assume that the system's default RLIMIT_NOFILE is 1024, and process A generates child process B through fork. B is a go application, so the go runtime will cache RLIMIT_NOFILE as 1024. When I set B's RLIMIT_NOFILE to 10000 through prlimit in A, and use exec.Command to create process C in B, C's RLIMIT_NOFILE is restored to 1024.
This behavior is incompatible with the operating system. It also caused problems with runc:
https://github.com/opencontainers/runc/issues/4195
The key code is as follows：

What did you see happen?
Reference https://github.com/opencontainers/runc/issues/4195
What did you expect to see?
RLIMIT_NOFILE should be correctly inherited to child processes

Please don't show us code in images.  Link to go.googlesource.com or GitHub instead.  Images are difficult to read.  Thanks.

If I understand this correctly, the problem is that if process A uses prlimit to change the resource limit in process B, then the Go standard library isn't aware of that when process B starts process C.
We can't change the current behavior in which process B passes the original RLIMIT_NOFILE value on to process C.  That is likely to break existing programs that do not expect a large RLIMIT_NOFILE, as discussed in #46279.  That issues shows real failure cases when we didn't do that, so we can't change back.
So I think the question is whether there is a way that process B could detect that the process limit was changed by some other process via prlimit.  In that case we should pass down the updated value, just as we already do if process B explicitly calls syscall.Setrlimit itself.

@golang/runtime

Please don't show us code in images. Link to go.googlesource.com or GitHub instead. Images are difficult to read. Thanks.
Ok, I've replaced the image with a commit link

I think there is also a get/set/set race situation here, please see https://github.com/opencontainers/runc/pull/4266 and https://github.com/opencontainers/runc/pull/4265 .

Go CL 393354 (in Go 1.19beta1) introduced raising the RLIMIT_NOFILE soft limit to the current value of the hard limit.
Further CLs (in Go 1.21, but backported to Go 1.20.x and 1.19.x) introduced more code in between getrlimit and setrlimit syscalls (see Go's src/syscall/rlimit.go).
In runc exec, we use prlimit(2) to set rlimits for the child (runc init) some time after we start it. This results in the following race:
runc exec (parent)                 runc init (child)
------------------                 -----------------
(see (*setnsProcess).start         (see init in src/syscall/rlimit.go)

                                   getrlimit(RLIMIT_NOFILE, &lim)
prlimit                            ....
                                   setrlimit(RLIMIT_NOFILE, &nlim)

So, I think we need to find a way to solve two problems:

A get/set/set race with prlimit;
How to know setted nofile limit by other process using prlimit.

So I think the question is whether there is a way that process B could detect that the process limit was changed by some other process via prlimit. In that case we should pass down the updated value, just as we already do if process B explicitly calls syscall.Setrlimit itself.

What's the progress now?
I think maybe there is no quick way to fix this issue? How about provide a public function in runtime to clear the cache? Let the user to decide whether the cache should be cleared or not.

We already have a public function to clear the cache:
    var r syscall.Rlimit
    syscall.Getrlimit(syscall.RLIMIT_NOFILE, &r)
    syscall.Setrlimit(syscall.RLIMIT_NOFILE, &r)

We already have a public function to clear the cache:
    var r syscall.Rlimit
    syscall.Getrlimit(syscall.RLIMIT_NOFILE, &r)
    syscall.Setrlimit(syscall.RLIMIT_NOFILE, &r)

We have considered this method, but it will cause new get/set race.

This only matters just before starting a child, so do it then.  If that is a race, then you have a race problem no matter what.

Maybe syscall.SysProcAttr should contain fields for setting the child's rlimits. runc could use that instead of the inherently racy practice of calling prlimit after starting the child.

Hi @lifubang, do you agree with what Ian wrote in https://github.com/golang/go/issues/66797#issuecomment-2119697489, or if not, could you briefly expand on why?
For the people reporting this here, is this something that affects Go code primarily consumed as a library, or package main? If there is not a valid workaround or solution in the near term, I wonder if a GODEBUG controlling the behavior could be temporary solution to help with backwards compatibility, or maybe that does not make sense?

if not, could you briefly expand on why?

Sorry for delay, because I'm in another busy thread.
I think it's easy to write a repro code, if someone has a intresting, it will be appreciated.

The explanation is like that:
If we use the way provided by Ian(and @ls-ggg) in process B which created by process A, this will cause a new race:

B:syscall.Getrlimit(syscall.RLIMIT_NOFILE, &r)
A:prlimit(B, a different nofile_rlimit)
B:syscall.Setrlimit(syscall.RLIMIT_NOFILE, &r)

Besides this, this way also causes us doing two unneeded syscall.
The core reason is that using Get/Set to clear the internal cache is not a atomic operation, I suggest to add a public method to clear this cache directly. For example: runtime.ClearSyscallRlimitCache().

I understand the race.  My point is that this only matters when you are about to start a child process.  So do it then.  There is already a race when starting a child process: you can start the child before or after the other process calls prlimit.  So the race that you mention doesn't make matters any worse.
Two additional system calls are trivial, it's not worth adding a very special purpose operation to avoid that.

We already have a public function to clear the cache:
    var r syscall.Rlimit
    syscall.Getrlimit(syscall.RLIMIT_NOFILE, &r)
    syscall.Setrlimit(syscall.RLIMIT_NOFILE, &r)

@ianlancetaylor the problem is, this relies on setrlimit(2) syscall returning no error, which is not always the case (for example, when we're in user namespace, we can't change rlimits for ourselves).
Perhaps something like this will fix the issue for us:
diff --git a/src/syscall/rlimit.go b/src/syscall/rlimit.go
index d77341bde9..8184f17ab6 100644
--- a/src/syscall/rlimit.go
+++ b/src/syscall/rlimit.go
@@ -39,11 +39,10 @@ func init() {
 }

 func Setrlimit(resource int, rlim *Rlimit) error {
-       err := setrlimit(resource, rlim)
-       if err == nil && resource == RLIMIT_NOFILE {
+       if resource == RLIMIT_NOFILE {
                // Store nil in origRlimitNofile to tell StartProcess
                // to not adjust the rlimit in the child process.
                origRlimitNofile.Store(nil)
        }
-       return err
+       return setrlimit(resource, rlim)
 }

I'm OK with that kind of change.

Perhaps something like this will fix the issue for us:

I think this needs more discussion.
Setting nofile rlimit error means we don’t set it successfully, if we clear it at this time, it will cause the new child process’s nofile rlimit in a wrong value state.
If I’m saying wrong, please let me know.

I think this needs more discussion. Setting nofile rlimit error means we don’t set it successfully, if we clear it at this time, it will cause the new child process’s nofile rlimit in a wrong value state.
If I’m saying wrong, please let me know.

Perhaps something like this will fix the issue for us:

I think this needs more discussion. Setting nofile rlimit error means we don’t set it successfully, if we clear it at this time, it will cause the new child process’s nofile rlimit in a wrong value state.
If I’m saying wrong, please let me know.

Perhaps something like this will fix the issue for us:

I think this needs more discussion. Setting nofile rlimit error means we don’t set it successfully, if we clear it at this time, it will cause the new child process’s nofile rlimit in a wrong value state.
If I’m saying wrong, please let me know.

Whoever calls Setrlimit will return an error in this case. They will know they are not able to set the limits.
In our (runc) use case, we just need to remove the cache. We can set the limit as well, but that's optional, since we will use unix.Prlimit as we always did to set the limit.
To me, this is the best middle ground between Go and runc needs.
PS we can discuss it further in https://github.com/opencontainers/runc/pull/4290 (i'm going to add go tip to its CI).

To me, this is the best middle ground between Go and runc needs.

Yes, I think this is enough for runc, but not enough for golang.

Whoever calls Setrlimit will return an error in this case.

Soft > Hard

I don't think it matters much.  If Setrlimit fails for an ordinary call, it's likely to also fail when it is called while fork/execing a child.

I looked into the manual page of setlimit(2), there are two errors we should consider:
 EPERM An unprivileged process tried to raise the hard limit; the
 CAP_SYS_RESOURCE capability is required to do this.
 EPERM The caller tried to increase the hard RLIMIT_NOFILE limit
 above the maximum defined by /proc/sys/fs/nr_open (see
 proc(5))

I think these two errors are normal errors that could be met by users.
For example(Not in runc):
If someone try to raise as more hard limit as possible in the process, but he hits one of EPERMs error, in a big probability he will ignores this ordinary call error, becuase this is just a try.
But at this time, the fork/execing still will be success.
If we clear the cache in Setlimit after got an error, the forked sub process's original nofile rlimit will be wrong.
It will make the user confused.
So, if there is a chance, I still suggest to add a specific public API: runtime.ClearSyscallRlimitCache().
But If all people think that to clear the cache using Setrlimit is an accepetable way, I have no strong objection opinion.
发件人：Ian Lance Taylor @.>
发送时间：2024年5月24日(星期五) 10:25
@.>
@.>; @.>
主　题：Re: [golang/go] syscall: caching RLIMIT_NOFILE is wrong implementation (Issue #66797)
I don't think it matters much. If Setrlimit fails for an ordinary call, it's likely to also fail when it is called while fork/execing a child.
—
Reply to this email directly, view it on GitHub <https://github.com/golang/go/issues/66797#issuecomment-2128379066 >, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF7IQBCUK55UBW3QQOW6NLZD2QJ7AVCNFSM6AAAAABGDYYRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGM3TSMBWGY >.
You are receiving this because you were mentioned.Message ID: @.***>

I am reluctant to add new API for this very special case.  It is very unusual for a program to care about the rlimit for child processes.  It is very unusual for a program to change its rlimit and fail.  The new API is only required for the intersection of those two very unusual cases.

One other issue is that Go runtime's caching of RLIMIT_NOFILE is based on the assumption that setrlimit is the only way to set the rlimits of a process. However, prlimit lets you set limits from a different process, and doing this doesn't update the cache because the Go runtime doesn't have any way of knowing that it happened (this is what we do in runc).
This causes several issues (one of which is the series of race conditions and logic issues we have now fixed in runc with stdlib workarounds by telling the Go runtime that we plan to change our RLIMIT_NOFILE with a dummy SetRlimit call) but the general takeaway I have is that this auto-adjustment logic isn't appropriate for general-purpose Go programs.

@cyphar I tend to take the opposite view, which is that the auto-adjustment logic works well for general-purpose programs, but not for special-purpose environments.  Across all uses of Go, using prlimit to change the rlimit of a different process is a very rare operation.
That said, we are certainly open to a different approach if you have any suggestions.

Is Go the right language for something like runc, or should runc be deprecated in favor of crun?  A container runtime must operate in extremely unusual environments and I’m not sure if it is reasonable to expect Go’s runtime to work there.  C, C++, and Rust all seem like better choices here.  It is true that C and C++ are not memory safe, but I expect most security problems in a container runtime to be logic errors interfacing with the Linux kernel, not memory safety problems.

Go is advertised as a systems language and in 2013-ish the decision was made to write Docker in Go, which lead to a lot of large projects using Go (such as most of the container ecosystem). Many of those projects use runc's code directly or use runc (because runc is by far the most commonly used container runtime). Deprecating it wouldn't make any sense.
The "maybe Go isn't the right language for this" ship has long since sailed. If we could travel back to 2013, I would argue that Go is the wrong language to use -- but at the time Go was the only language that made sense to use (Rust wasn't ready, and writing Docker in C/C++ would've lead to more security issues because Docker is a privileged daemon that has to deal with far more things than runc).
FWIW my experience is that Go isn't really a "systems language", it's more of a language for writing tools and web servers that don't require a lot of fine-grained control that system languages provide.
When I submit bug reports as a runc maintainer, I'm more than aware that we are not seen as a welcome member of the Go community because we are always seen as "doing weird things" (such as being put on the "wall of shame" for trying to work around problems in the Go runtime that are not documented and took us ages to figure out how to fix). I try to avoid opening bug reports for these kinds of issues because I know that they will just be ignored.

I'm sorry that you don't feel like a welcome member of the community.  Certainly my goal is to work with tools like runc to find solutions that will work for the whole community.
Using go:linkname to reach into the runtime is an example of something that simply doesn't work for the whole community.  That doesn't mean that the problems can't be solved.  It means that go:linkname is the wrong solution.
I stand by my claim that using prlimit to change the rlimit of a different process is a very rare operation.  As I've said, I am certainly open to figuring out a way to make this work for you.  After all, this issue is still open.  But I don't think the answer is "the way that we do things is the only way that matters."  There are other cases that matter, whether we consider Go to be a systems language or not.
For RLIMIT_NOFILE the Go runtime is trying to handle a real problem that real programs were running into in practice (#46279).  The caching to reset the limit for child processes, also discussed on that issue, is also there to handle a real problem.  And you also have a real problem.  So let's figure out a way to solve all those problems, rather than saying that some of them don't matter.

@cyphar If os/exec could configure the child's rlimits before execing it (via some new fields in syscall.SysProcAttr), would that eliminate runc's need to use prlimit?

Using go:linkname to reach into the runtime is an example of something that simply doesn't work for the whole community. That doesn't mean that the problems can't be solved. It means that go:linkname is the wrong solution.

We have opened RFCs to try to solve these problems without using go:linkname (such as #67639), it's just that the first version of the fix usually does require go:linkname because we sometimes run into cases where that really is the only way to fix an immediate problem without going through a long RFC process (we'd need #67639 to fix a CVE if we couldn't go:linkname).

For RLIMIT_NOFILE the Go runtime is trying to handle a real problem that real programs were running into in practice (https://github.com/golang/go/issues/46279). The caching to reset the limit for child processes, also discussed on that issue, is also there to handle a real problem. And you also have a real problem. So let's figure out a way to solve all those problems, rather than saying that some of them don't matter.

I never said they don't matter, I was saying that the current way of doing it and the fixes that have been applied to it are flawed because they're designed around the idea that Go processes will always be the process that sets their own rlimits. I don't think this is true in general -- sysadmins sometimes need to change process rlimits for long-running daemons. (runc is not a long-running daemon, this is just something that seems like a problem to me in general.)
We can work around this in runc because while the same process doesn't set its own rlimit, both processes are runc and so we can co-ordinate things (which we've already done -- this issue is no longer a problem for us). My concerns are purely based on wanting to make sure that this issue doesn't bite other users where they can't work around the problem.
A "good enough" solution would be to save the rlimits set by Go during init and then check if the process rlimits are different when doing exec. If the value is different (or the Go process tried to do Setrlimit), the Go runtimne shouldn't touch them. There is theoretically a small TOCTOU race but you could argue that there would be a race anyway between a sysadmin doing prlimit and the fork+exec.

If os/exec could configure the child's rlimits before execing it (via some new fields in syscall.SysProcAttr), would that eliminate runc's need to use prlimit?

Maybe, but we have already fixed the issue for runc (by doing a dummy Setrlimit which works now that Go will clear the cache regardless of whether it fails) and so we don't have a strong need for such a feature. If it existed, we might switch to it but I'm not sure (if a user sets really restrictive limits, we probably don't want to apply them to the entirety of runc init because it could lead to errors caused by runc not the container workload -- this is something we have to consider for cgroups, but this might also just be a theoretical concern).
However, that wouldn't help with the case where a sysadmin does a prlimit, which is the case I'm worried about (not from runc's standpoint, but as a Go programmer that has written long-running daemons that could be adjusted by a sysadmin this way).

I never said they don't matter, I was saying that the current way of doing it and the fixes that have been applied to it are flawed because they're designed around the idea that Go processes will always be the process that sets their own rlimits. I don't think this is true in general -- sysadmins sometimes need to change process rlimits for long-running daemons. (runc is not a long-running daemon, this is just something that seems like a problem to me in general.)

Quite agree.

I'm sorry that you don't feel like a welcome member of the community. Certainly my goal is to work with tools like runc to find solutions that will work for the whole community.

I think cyphar's original mean is that Runc maintainers always submit issues which are difficult to resolve in go community, and then we had to decide to using some weird ways to fix them in my own, for example go:linkname. I think this is a figure of speech, not a real feeling.
We know that go:linkname is not recommended, but we just only take it for a short term solution to give golang community more time to fix.

Yes, we didn't want to submit these issues for no reasons, because that are really problems met by runc. The goal of submitted them to golang community is to fetch some possible helps from others. I think golang maintainers gave us lots of solutions, though some of solutions are not perfect. We should say thanks to these nice persons.

We understand that these issues filed by us are not critical for golang, golang maintainers have lots of more important things to do. So we should have a thorough discussion instead of rushing to fix it with imperfect methods, though these are not cared by other golang users.

So let's figure out a way to solve all those problems

For this specific issue, I think the original implementation(#46279) is not recommended. This is the core reason of this discuss. I think that if we want to raise the soft limit of nofile, we should let the users to do this, we should not do it silently in runtime. It's the responsibility of the user, but not the runtime. I think a language runtime should provide more and more controllable functions for the users, but not make a decision for them. Once we have a wrong beginning, we need to add more imperfect implementations to fix some unimportant issues, it's not worth to do.

My Suggest way: I think we should raise this soft limit in their own tools when they need to do it, for example: cmd/gofmt, cmd/go, but not in go runtime.

Thanks.

@lifubang Thanks, but we came to a decision on #46279 and we would need a very good reason to reverse that decision.  The current situation seems better for the vast majority of Go programs even if it is worse for a few.

@cyphar Thanks for the suggestion.  What do you think of https://go.dev/cl/607516?


Cell fails to show properly after creation

Steps to reproduce:

Create a new query under Explore
Save it to a specific dashboard

Expected behavior:
I expect it to show the cell properly
Actual behavior:
It shows an error message saying I should report a bug. After refreshing it shows up fine though.
This behaviour is consistent over the few times I've tested it.
Environment info:

System info: Linux 4.18.0-147.8.1.el8_1.x86_64 x86_64
InfluxDB version: InfluxDB 2.0.0-beta.10 (git: d00706dea8) build_date: 2020-05-31T19:20:37Z
Browser: Firefox on Linux

Logs:
From the browser console:
Empty string passed to getElementById(). 235 Popover.tsx:217:35
Empty string passed to getElementById(). Overlay.tsx:60:33
Empty string passed to getElementById(). 2 Popover.tsx:217:35
Empty string passed to getElementById().  This should be available by opening your network tab in your browser and viewing the dashboard(s) response.

This is the response from a get request to /api/v2/dashboards
get_dashboard.json.txt
and this is the exported dashboard:
export.json.txt

@NULLx76 it doesn't seem like there were any errors in the logs you linked through to us. Do you happen to know if the issue still exists / whether the issue went away after rerendering the dashboard? I'm also curious as to whether you were referencing any variables in that cell's query?


mysql: update sql-mode default

Change TiDB to use the same default as MySQL 5.7
Depends on https://github.com/pingcap/tidb/pull/8278 (merged)

See also: https://github.com/pingcap/docs/pull/728 -- it turns out TiDB has great support for MySQL's SQL modes.  It just doesn't enable them all by default like mysql does :-)

LGTM @zimulala

Ping @zimulala

should we file a PR in TiDB to test this change? @morgo @tiancaiamao

@zz-jason The corresponding TiDB PR is https://github.com/pingcap/tidb/pull/8278
NO_ZERO_DATE did break the set suite, but it's since been fixed.

LGTM
PTAL @zz-jason @zimulala


Allow annotating part of a line

I think it would be nice if you could annotate just part of a line, instead of the entire line. Markers will be able to tell students more precisely where they made mistakes.
For example, if students have to write a long Bash command, you'd be able to  just highlight the part that's wrong. For example:
cat pcat | egrep 'put' | wc -l | diff correct_count -  # student's code
|--------------------|
highlight just this part of the line and annotate with "use egrep 'put' pcat"

@david-yz-liu I have a rough implementation of this now, but it has presented a few issues. It will require a bit more work to allow multiple annotations on the same line and the unglow method might need some work.
Im just wondering if its okay that I work on this next week as well or should I get started on the other issues I was assigned?

@spring-ryanc I'd like to see the work you've done so far. I've created a new branch off of the main repo called line-annotations; please make a pull request into that branch and wait for feedback.
In the mean time, working on #1850 and #1981 should be a nice break for you.


Seperate segmented algorithms for count and count_if

Seperate segmented algorithms for count and count_if
Replace tag_invoke with tag_fallback_invoke
Any background context you want to provide?
Issue #5156
Issue #5204

Can one of the admins verify this patch?

retest

@Jedi18 the CircleCI builder is complaining about a couple of unused using directives here: https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/6926/workflows/a28cbe9c-935e-434d-89c2-a7601ceafdc9/jobs/241207/steps


Add weatherstack api option in Weather category

Thank you for taking the time to work on a Pull Request for this project!
To ensure your PR is dealt with swiftly please check the following:

[x] Your submissions are formatted according to the guidelines in the contributing guide
[x] Your additions are ordered alphabetically
[x] Your submission has a useful description
[x] The description does not end with punctuation
[x] Each table column should be padded with one space on either side
[x] You have searched the repository for any relevant issues or pull requests
[x] Any category you are creating has the minimum requirement of 3 items
[x] All changes have been squashed into a single commit

Thanks for contribution @nitinbhojwani :)
This API already exists in readme.md 😅


[MKLDNN]Enhance Quantization APIs and Tutorial

Description

Create a MKL-DNN specific user-level api quantize_model_mkldnn which combines fusion and quantization.

Enable resnet50_v1b quantized model.

Split quantize_model API into three parts to make it flexible for users to integrate quantization flow into their project:
1)quantize_graph: quantize fp32 model to int8 model w/o calibration and return a collector for collecting calibration information in the next step.
2)[outside api]: users need only add a few lines together with mod.forward for collecting calibration information.
3)calib_graph: generate calibrated model based on filled collector.

Draft a tutorial to introduce How to quantize custom models for production-level inference with MKL-DNN backend.

@pengzhao-intel @TaoLv @ZhennanQin @ciyongch
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@anirudh2290 @ThomasDelteil as we discussed in the forum,  we post the developer guide for the user who wants to integrate quantization flow into their script.
CC @reminisce @ZhennanQin @ElaineBao
Any suggestion is highly appreciated :)

http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-15448/11/tutorials/mkldnn/MKLDNN_QUANTIZATION.html

@KellenSunderland please help take a review too :)

nit: use lower case in the name of document.

@ThomasDelteil Comments addressed, Please take a look at again:)

@mxnet-label-bot add [MKLDNN, Doc]

@aaronmarkham could you help take a review for the new document?

@ThomasDelteil Would you mind to take a review again?

Will do, at a conference this week, limited bandwidth but next week I'll have some availability to look into quantization again and get back to you on the different email threads as well, apologies for the delay!

Will do, at a conference this week, limited bandwidth but next week I'll have some availability to look into quantization again and get back to you on the different email threads as well, apologies for the delay!

Sure :)  Have a good trip on AMLC.
Maybe you can bring more amazing ideas to improve the API and usability of quantization flow from the conference :) We're highly appreciated for the inputs and feedbacks.
Thanks in advance.

@ThomasDelteil Could you please review this PR once you have time? Thanks!

@ThomasDelteil do you have a chance to review this week?
We have other improvements in GluonCV which depends on this PR.

@ciyongch @ZhennanQin @ElaineBao please take a review and test in local.

docs look good to me.

@ThomasDelteil we are going to merge this PR in 24 hours if no further comments since other improvements depend on this.

Merging now. We're continually improving the quantization flow so any suggestions and feedbacks are highly appreciated.


Babel: Disable loading project-wide config

If this plugin is used in a project with a Babel config (eg. babel.config.js), those settings will be used when inlining function variables as a project-wide config.
This can lead to unintended transforms being applied to functions eg. functions being transpiled in a browser context and then failing on execution due to missing polyfills.
Let's disable the project-wide config when using Babel to inline environment variables.

Thanks for the improvement!


Suggesting a project but form doesn't recognize the programming language

Hi!
I was submitting my project to the event, it is a videogame in Unity developed in C#, but at the time I enter the language programming the page states C# isn't a language programming.
Please fix this.

@LauraLaureus I had a quick look at this and couldn't replicate:

Is it possible you had leading or trailing spaces? Those should probably be stripped those if that was the case.

We can probably remove that field as we pull it from the repo anyway

Don't rely on pulling it from the repo
Some times to to generated files or polygot projects, the language the repo tells you is not necessarily the langue that skills are needed in

That can be fixed on the repo itself with linguist config

I did not know that. Off track, but do you have a link handy?
Mordechai Zuber - Contact Using Hop
On November 13, 2016 at 16:27 GMT, Andrew Nesbitt<EMAIL_ADDRESS>wrote:
That can be fixed on the repo itself with linguist config
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

https://github.com/github/linguist/blob/master/README.md#overrides

I submitted the project stating it's C, but  now I edited it and system allows me to say it's C# . Did you do something?

Nope, haven't changed anything

@LauraLaureus Are you able to confirm whether this issue was resolved for you? If not, I can continue to look into it. Thank you! 😸

@xadamy it's resolved form me, I just suggest another project in C# and it was successfully accepted.
Sorry for the dealy but I had a lot of thing to do lately.

@LauraLaureus No problem! Thanks for confirming! I'll close this for now but feel free to re-open if you see it again


fix empty_productions schema validation

It should be checking nested expressions of sequences

@AntonyBlakey happy to discuss it further, but so far, we have always assumed that a parser must consume something, or report an error. If something is optional or zeroOrMore for example, it should be specified as such in the containing production. I believe it leads to a cleaner API, and straight-forward error reporting. But happy to revisit if you disagree.


Empty description file of courses

Downloaded text file of courses are empty. Is it just me?
Can you add those to text file if you're thinking of rebuild:
Description
/
DescriptionDescriptionDescriptionDescription
DescriptionDescriptionDescription
/
Author: xxxxx yyyyyyy
Released xx/xx/xxxx
Skill Level: Beginner/Appropriate for all/etc
Duration: 3h 18m
Topics include:
•xxxxxxxxx
•yyyyy
•zzzzzzzzzzz
•ffff
•tttttttttt
Subjects:
Business / Data Analysis / Project Management / etc
Software
Github / Excel / After Effects / etc

Will it fix ? @r0oth3x49

@WaxKitten can you explain why you want to add all those things? it think long/short descriptions are good enough isn't?

This txt problem solved by using linux.

This txt problem solved by using linux.

How do you solve the description error?
i am using ubuntu and the description file is always empty when downloading courses.
Thanks.


Instantiation performance improvement

I'm working on an application where I create one Wasm Instance per HTTP request.
Now I have run into a performance issue where most of the response time is spent on instance creation. I'm not sure how I could structure my app to improve this.
I run a profiler to measure where time is spent exactly and here are some results:
47% wasmtime::func::Func::wrap
    - wasmtime::trampoline::generate_raw_func_export
16% wasmtime_runtime::instance::InstanceHandle::dealloc
    - core::ptr::drop_in_place
16% wasmtime::linker::Linker::instantiate
    - wasmtime::instance::Instance::new
 7% wasmtime::externals::Memory::new
    - wasmtime::externals::Memory::new
      -wasmtime::trampline::generate_memory_export
...

My biggest issue is the almost 50% of time spent wrapping closures for the Linker (Linker::func). But I don't see a way around this as every Linker is connected to a Store, and because I need to create a Store per Instance I can't reuse the Linker (or they would belong to different Stores). Also, I'm capturing some per request environment in the closures and re-using Linkers would be hard in this case.
For now it's still ok, but as I keep adding functionality I'm afraid this is going to be a big issue. Is there a way I could improve this?
Also the 16% dealloc seems a bit big, but I'm not sure where this is exactly coming from.

This kind of use case would indeed be great to make faster! While for all I know there might be some low-hanging fruit left in the operations showing up in your profile, I wonder if a different approach might not be better:
Instead of actually creating a new instance for each request, might it also be possible to reset existing instances, or more specifically their Memory, stack, and tables?
You mention capturing per-request data in closures, so that part might need a different solution. Perhaps you could store that as instance-associated data?
@alexcrichton can you comment on how difficult it'd be to do this kind of instance-resetting?

Instead of actually creating a new instance for each request, might it also be possible to reset existing instances, or more specifically their Memory, stack, and tables?

This was the first idea I also came up with. Having an Instance::reset() would be ideal. Then I just could run a pool of ready Instances and save a lot of work.  Zeroing out the memory could be potentially much faster than creating new linear memories. But I'm not sure how hard it would be to implement such a thing.

You mention capturing per-request data in closures, so that part might need a different solution. Perhaps you could store that as instance-associated data?

I can work around this by capturing a structure that I internally change for each request. In some way this would be "instance-associated data".

Ok, great! I guess this would be about resetting the store, specifically, so that should probably be reflected in the name.
If this turns out not to require deep architectural changes, would you potentially be interested in working on adding this to Wasmtime, @bkolobara?

Yes, this is an important issue to me and I'm able to dedicate some time to it.

Excellent! Let's wait for Alex to weigh in then.

Resetting memories, globals, and tables shouldn't be too hard as long as there aren't any frames on the stack. This way we wouldn't need to reset the stack, which has bigger implications (like spec deviance, for one).

Thanks for the report here @bkolobara! This is definitely a situation we'd like to be quite fast, and it sounds like it's not quite up to par at the moment!
Would it be possible to share some code you're using? I'd love to dig in a bit more into a microbenchmark or something like that  to see if there's any low hanging fruit.
For resetting the Store, I'm not sure how easy that would be. It could be very tricky to pull off safely and I'd prefer to go the route of optimizing what we have there already first if possible (not a ton of optimization effort has gone in just yet). I think my ideal solution if optimization doesn't work though would be to somehow reuse the Linker so you don't have to recreate the entire host environment each time, but you could instead create it once globally or once per thread maybe (or something like that).

Would it be possible to share some code you're using? I'd love to dig in a bit more into a microbenchmark or something like that to see if there's any low hanging fruit.

To not dump the whole unrelated project here, I will just c/p the part handling instantiation here (it is mostly straight forward code):
...
let store = Store::new(&engine);
let mut linker = Linker::new(&store);

let memory = match memory {
    MemoryChoice::Existing(memory) => memory,
    MemoryChoice::New(min_memory) => {
        let memory_ty = MemoryType::new(Limits::new(min_memory, None));
        Memory::new(&store, memory_ty)
    }
};

let environment =
    ProcessEnvironment::new(engine, module.clone(), memory.data_ptr(), other_args);

linker.define("env", "memory", memory)?;
// A lot of
let env = environment.clone();
linker.func("env", "func1", move |index: u32| { ... env.something ... })?;
...
let env = environment.clone();
linker.func("env", "func2", move |index: u32| { ... env.something ... })?;
...

let instance = linker.instantiate(&module)?;
let func = instance.get_func("response").unwrap();
func.call(&[Val::from(arg1 as i32), Val::from(arg2)])?;

 This is not that bad, but considering that the func.call finishes really fast for simple endpoints most of the time is spent on instantiating.

... would be to somehow reuse the Linker so you don't have to recreate the entire host environment each time, but you could instead create it once globally or once per thread maybe (or something like that).

I attempted to do something like this, but got stuck on the fact that each Linker is created from a Store and can't be used with others. So I need to keep a Linker & Store pair preserved. But if I don't drop the Store I can't drop the Instances associated with it.

Thanks for the info! That should be plenty good for investigating. As one other piece of info, how many functions are you defining via linker.func?
Also yeah, you can't reuse Linker across a Store today. You're using wasmtime how it's intended, we just need to make it faster or tweak the  recommended idioms and APIs to make it faster :)

how many functions are you defining via linker.func?

16, but I will need much more as I keep adding features.

@bkolobara hey wanted to let you know that I haven't forgotten about this (although this is a bit delayed). I've done some small work here and there to optimize this use case, but I wanted to drill a bit more into the numbers that you were seeing. I whipped up a small benchmark with a number of functions of differing signatures, and on my computer that's taking ~50us per iteration. You mentioned you were getting 900us, so I was wondering if you could run that locally and see how much time it's taking for you?
I'd ideally like to get a gauge on what the expected scaling factor is in the difference between these two environments.

Thanks a lot for looking into this @alexcrichton! Running your benchmark produces also a result of around ~60us on my machine. This got me curious so I just dumped the part I was previously benchmarking with a let now = std::time::Instant::now()  & let elapsed = now.elapsed().as_micros() wrapper into citerion and now I'm getting ~120us for the same code.
I wasn't sure why the difference was so big, so I went ahead and wrapped the same code block again with Instant::now() inside my app. This resulted in:
...

I'm using multiple threads to create the instances and handle the requests. If I limit the execution to only 1 thread I'm getting more consistent results:
...

This is much closer to the citerion results.
I assume that I'm getting a big performance hit from cache locality? Or maybe the shared Module & Engine become a bottleneck? Nothing else is shared between the threads.
I will try to investigate this further and report back, but I'm not sure how to exactly pinpoint this kind of issues.

@alexcrichton I have created a modified version of your benchmark using Rayon to instantiate in parallel.
Using into_par_iter() or into_iter() doesn't see to make any difference. I would expect the parallel one to take less time as the CPU utilisation is much higher during the benchmark. I could also be doing something obviously wrong 😄.

Hm interesting! What plaform are you running on and what does the cpu count look like? I'm not sure if this means that there's high contention, though, it sort of makes sense that the per-iteration time doesn't change too too much in parallel vs non-parallel because there shouldn't be contention. I don't really understand the math behind criterion though to understand whether this is an expected result or not.
It is interesting though that with a threaded version of your application you're seeing higher overheads than without. That may point to a threading overhead though rather than a wasmtime overhead?
In any case though we're always looking for ways to improve instantiation time and with new work underway to merge lucet and wasmtime I suspect we'll continue to drive this number down.

With this rfc merged and implemented I think this is now fixed.


dist content-hash different on different path

Version
3.0.5
Reproduction link
https://github.com/zhangbobell/vue-cli-content-hash-reproduce
Node and OS info
Node v8.11.2 / yarn 1.10.1 / macOS 10.14 (18A391)
Steps to reproduce
Do the following 4 steps in two machines or  in one machine different path, compare the content-hash in dist/js/app.<content-hash>.js, you will find them not the same.
git clone https://github.com/zhangbobell/vue-cli-content-hash-reproduce.git

cd vue-cli-content-hash-reproduce

yarn

NODE_ENV=production yarn build

I've test in two machines, the result shows below:
Result on machine A (app.js content-hash is efe1aa10):

Result on machine B (app.js content-hash is d9410857):

What is expected?
The two content-hash of app.js on two machines will be the same.
What is actually happening?
They are different

The following is my Vue-Cli settings:

I have debug this for some hours, but did not have any valuable result. But I'm sure it has something to do with babel-polyfill, since the difference disappears when I choose No with Use Babel alongside TypeScript for auto-detected polyfills? (Y/n) prompt.
It seems that babel-polyfill will inject absolute path into the compiled js, that lead this bug.
I wish someone could help to debug this.
Thanks for providing a awesome tool !

You can just create two vue projects with vue-cli 3.0 in different directory (using the above settings), then both run NODE_ENV=production yarn build, you'll easily find your content-hash of app.js is different.
Besides, when do not use babel alongside, the content hashes of  the two app.js will be the same.

ping..., has anyone came up with a solution?

@zhangbobell this is a problom since update to vue cli3, the same issue with #1728. No one know how to fix it...

This is probably related to some part of the code (ours or a loader or plugin) using absolute paths to require files. Since the hashes are calculated from the source code, if we have
require(/some/absolute/path/to/some.js)`

somewhere in the generated source, the has will be different.

@LinusBorg Thanks for your reply. Yes, I'd read the blog before, link from another issue. And I guess it has something to do with babel-polyfill since the hash become identical when I do not choose babel alongside with TypeScript during creation prompt.
And also I'd searched in babel issues, and someone has encounter with it before. But not really same with ours. So.. Just a guess. I could not easily debug it, so I submit this issue.
Could anyone lend some help ?

@zhouxinyong Thanks your discussion, seems really not very easy to locate the problem. Hope someone knows it.

It's due to this line: https://github.com/vuejs/vue-cli/blob/2ac64d6de116d992c410d375ddcacab98b795f64/packages/%40vue/babel-preset-app/index.js#L148
I think we need to expose an option here.

@sodatea Maybe this has no impact about the bug ? I just modified this line of code, the content hash did not changed.

@zhangbobell Explicitly setting absoluteRuntime to false and then rm -rf node_modules/.cache did fix this issue as I tested just now.

@sodatea Oh, sorry, I just rerun without clearing the cache. I've test just now, it's really the same. Thanks very much.
Maybe I could came up with a Pull Request to fix it. 😄

@zhangbobell
😀Yeah send a PR please.
The best solution is to provide a good default and expose an option for customization.
We use absoluteRuntime to ensure the correct version is used.
It would be great if we can automatically enable this feature by detecting @babel/runtime's version in the root node_modules directory.
If the detection is not doable, then we can enable absoluteRuntime by default and document its usage for users who really need a consistent hash.

With absoluteRuntime set to false, I get:

Unknown option: .absoluteRuntime.

My babel.config.js:
module.exports = {
  presets: [
    '@vue/app', { absoluteRuntime: false }
  ]
}

With absoluteRuntime set to false, I get:

Unknown option: .absoluteRuntime.

My babel.config.js:
module.exports = {
  presets: [
    '@vue/app', { absoluteRuntime: false }
  ]
}

I did rm -rf node_modules/.cache before build and I use version 5.1.0.

I think you are missing an array level, see:
https://github.com/vuejs/vue-cli/issues/3533#issuecomment-467864114


[Ubuntu] Fix composer version

Description
The output format compose version has been changed: https://github.com/composer/composer/commit/03b7882ac231d19e9373ed33a8e71d7bb5b280c1, which is a custom format.
Related issue:
Check list

[x] Related issue / work item is attached
[x] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run ubuntu1804, ubuntu2004

Which solution is better? https://github.com/actions/virtual-environments/pull/5334

Which solution is better? #5334 I can remove my PR since it's likely to add noise compared to your solution.

No need to delete, because your PR will fix output for Windows and I hope composer team will not change output notation soon.


Fix Status Updates

My unit tests were making an incorrect assumption about the format of status dicts from the Wink API.
This was causing all status updates to fail.
This should fix issue #35

Coverage increased (+0.5%) to 85.301% when pulling de4965eebf59010bee4651a683b084b1e31ba607 on fix-update into 33f88002ea17da881189a09f13b53a6954cea458 on master.

Coverage increased (+0.4%) to 85.266% when pulling 751c0643b909d4242fbbbff241b1de3d3465c7db on fix-update into 33f88002ea17da881189a09f13b53a6954cea458 on master.

Coverage increased (+0.4%) to 85.266% when pulling 751c0643b909d4242fbbbff241b1de3d3465c7db on fix-update into 33f88002ea17da881189a09f13b53a6954cea458 on master.


Make Automatic State Store Encryption No Longer a Preview Feature

In what area(s)?

/area runtime

Expected Behavior
This is preview feature that was introduced in v1.4 release https://github.com/dapr/dapr/pull/3589
Original issue https://github.com/dapr/dapr/issues/1090
Actual Behavior
Make this a GA feature in the current release, with ensuring test coverage, update docs and examples.

RELEASE NOTE:

Closed via #4318.


protocmp: Panic on embed message field comparison

What version of protobuf and what language are you using?
Version: 1.34.2
What did you do?
Compare embed message field.
// in testing/protocmp/xform_test.go
	t.Run("embed message", func(t *testing.T) {
		type embedMessage struct {
			*testpb.TestAllTypes
		}
		type hasEmbedMessage struct {
			Embed *embedMessage
		}
		if diff := cmp.Diff(&hasEmbedMessage{}, &hasEmbedMessage{}, Transform()); diff != "" {
			t.Errorf("Transform() mismatch (-want +got):\n%v", diff)
		}
	})

What did you expect to see?
No panic.
What did you see instead?
Panic at https://github.com/protocolbuffers/protobuf-go/blob/master/internal/impl/api_export.go#L144 by call method for nil pointer.
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x6fd337]

goroutine 7 [running]:
testing.tRunner.func1.2({0x73fa80, 0xab84b0})
	/go/1.22.0/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
	/go/1.22.0/src/testing/testing.go:1634 +0x377
panic({0x73fa80?, 0xab84b0?})
	/go/1.22.0/src/runtime/panic.go:770 +0x132
google.golang.org/protobuf/testing/protocmp.(*embedMessage·3).ProtoReflect(0x79e0a0?)
	<autogenerated>:1 +0x17
google.golang.org/protobuf/internal/impl.Export.MessageOf({}, {0x79e0a0, 0x0})
	/go/src/github.com/protocolbuffers/protobuf-go/internal/impl/api_export.go:144 +0xa3
google.golang.org/protobuf/testing/protocmp.Transform.func3({0x79e0a0?, 0x0?})
	/go/src/github.com/protocolbuffers/protobuf-go/testing/protocmp/xform.go:238 +0x19e
reflect.Value.call({0x72a220?, 0xc0002564f0?, 0x40?}, {0x7a1409, 0x4}, {0xc0000d9570, 0x1, 0x449d0b?})
	/go/1.22.0/src/reflect/value.go:596 +0xce5
reflect.Value.Call({0x72a220?, 0xc0002564f0?, 0x196?}, {0xc0000d9570?, 0x4120bb?, 0xc0000783b0?})
	/go/1.22.0/src/reflect/value.go:380 +0xb9
github.com/google/go-cmp/cmp.(*state).callTRFunc(0xc000261220, {0x72a220?, 0xc0002564f0?, 0x79e0a0?}, {0x79e0a0?, 0xc0000783b0?, 0xc0000a4650?}, {0x4120bb?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:333 +0x225
github.com/google/go-cmp/cmp.(*transformer).apply(0xc000228c40, 0xc000261220, {0x79e0a0?, 0xc0000783b0?, 0xc0000a46c0?}, {0x79e0a0?, 0xc0000783b8?, 0x87e0e0?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/options.go:320 +0x139
github.com/google/go-cmp/cmp.(*state).tryOptions(0xc000261220, {0x87e0e0, 0x79e0a0}, {0x79e0a0?, 0xc0000783b0?, 0x10?}, {0x79e0a0?, 0xc0000783b8?, 0xacef20?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:303 +0x109
github.com/google/go-cmp/cmp.(*state).compareAny(0xc000261220, {0x877320, 0xc0001fab00})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:258 +0x4c7
github.com/google/go-cmp/cmp.(*state).compareStruct(0xc000261220, {0x87e0e0, 0x748a40}, {0x748a40?, 0xc0000783b0?, 0x4187bf?}, {0x748a40?, 0xc0000783b8?, 0x0?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:427 +0x586
github.com/google/go-cmp/cmp.(*state).compareAny(0xc000261220, {0x877380, 0xc000228cc0})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:286 +0xcce
github.com/google/go-cmp/cmp.(*state).comparePtr(0xc000261220, {0x87e0e0, 0x717600}, {0x717600?, 0xc0000783b0?, 0x743820?}, {0x717600?, 0xc0000783b8?, 0x40?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:579 +0x373
github.com/google/go-cmp/cmp.(*state).compareAny(0xc000261220, {0x8773e0, 0xc000228c80})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:292 +0xb72
github.com/google/go-cmp/cmp.Diff({0x717600, 0xc0000783b0}, {0x717600, 0xc0000783b8}, {0xc000256520?, 0xaa3860?, 0xc000076760?})
	/go/pkg/mod/github.com/google/go-cmp@v0.5.5/cmp/compare.go:119 +0x75
google.golang.org/protobuf/testing/protocmp.TestTransform.func6(0xc00026c9c0)
	/go/src/github.com/protocolbuffers/protobuf-go/testing/protocmp/xform_test.go:305 +0xab
testing.tRunner(0xc00026c9c0, 0x7b81b0)
	/go/1.22.0/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 6
	/go/1.22.0/src/testing/testing.go:1742 +0x390

Anything else we should know about your project / environment?

Embedding a proto message like this
type embedMessage struct {
  *testpb.TestAllTypes
}

Generates a lot of methods that forward to the generated testpb.TestAllTypes type. protocmp therefore thinks that this is a proto message (it implements the correct interface). In this case, something equivalent to
func (e *embedMessage) ProtoReflect() protoreflect.ProtoMessage {
  return e.TestAllTypes.ProtoReflect()
}

The problem is that protocmp is passing this type to MessageOf in the first place. The documentation is pretty clear that the type must be a "message type generated by protoc-gen-go and must be a pointer to a named struct type". OTOH, protocmp has no way of knowing that *embedMessage is not a proto type, after all *embedMessage implements the correct interface.
All in all, I don't think this is a problem that can be fixed without severely breaking backwards compatibility. If you must embed a proto, and I don't think embetting is good idea for any type you don't fully control, then you are responsible for making sure that it really behaves like a proto message.

I think we can implement this feature without losing compatibility.
Please check the PR.

Thanks for the PR.
IIUC, the PR assumes that there are no implementations of proto.Message that rely on embedding another proto.Message. That's unlikely to exist, but there are a lot of proto users out there and therefore even unlikely things like that happen regularly.
I am also not convinced that the additional complexity is worth it: There are number of functions that take a proto.Message, handling this differently in protocmp is bound to cause confusion.
I don't think this solution should be accepted.

I think protocmp is totally broken for proto.Message embed structs and no one is happy with this behavior at the point of comparing of go-cmp's one.
I keep this issue open for other users facing the same issue.

Keep in mind that your type is implementing proto.Message if you embed a proto message. If you do that and pass it to a function that accepts a proto.Message it's your responsibility to implement it correctly. Granted, it would be nice if that happened automatically, but it's not. I think a fix should be on that level. If that's not possible, so be it.
Either way, as I said before, embedding proto messages is not a good idea. I would be very surprised if protocmp is the only sharp corner you'll run into with that approach.

A protobuf message is any type that implements "google.golang.org/protobuf/proto".Message.
The *embedMessage type implements proto.Message, therefore it's a message. However, a nil *embedMessage panics when its ProtoReflect method is called, therefore the panic as observed here. You either need to take care not to pass a nil *embedMessage to something that expects a message, change it to not panic in this case, or change it to not implement proto.Message.
For example, you could avoid panicing:
type embedMessage struct {
  *testpb.TestAllTypes
}

func (m *embedMessage) ProtoReflect() protoreflect.Message {
  var p *testpb.TestAllTypes
  if m != nil {
    p = m.TestAllTypes
  }
  return p.ProtoReflect()
}

Or you could avoid implementing proto.Message:
type doNotImplementMessage struct{}
func (doNotImplementMessage) ProtoReflect() protoreflect.Message

type embedMessage struct {
  *testpb.TestAllTypes
  doNotImplementMessage
}

Or, as @znkr suggests, you could avoid embedding altogether, which is probably the simplest solution.


Could not build on macOS 12.0.1 and Apple M1 CPU.

I had a combination of macOS 12.0.1 and Apple M1 CPU fail in the build.
Is this test something I really need to do to build?
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/satoy11/work/maya2gltf/Maya2glTF/build/GSL/src/GSL-build
[ 27%] Performing build step for 'GSL'
[ 17%] Built target catch
Consolidate compiler generated dependencies of target test_catch
[ 20%] Building CXX object tests/CMakeFiles/test_catch.dir/test.cpp.o
In file included from /Users/satoy11/work/maya2gltf/Maya2glTF/build/GSL/src/GSL/tests/test.cpp:26:
/Users/satoy11/work/maya2gltf/Maya2glTF/build/GSL/src/GSL-build/external/include/catch/catch.hpp:4167:13: error: unrecognized instruction mnemonic, did you mean: bit, cnt, hint, ins, not?
CATCH_BREAK_INTO_DEBUGGER();
^
/Users/satoy11/work/maya2gltf/Maya2glTF/build/GSL/src/GSL-build/external/include/catch/catch.hpp:1392:75: note: expanded from macro 'CATCH_BREAK_INTO_DEBUGGER'
#define CATCH_BREAK_INTO_DEBUGGER() if( Catch::isDebuggerActive() ) { CATCH_TRAP(); }
^
/Users/satoy11/work/maya2gltf/Maya2glTF/build/GSL/src/GSL-build/external/include/catch/catch.hpp:1371:34: note: expanded from macro 'CATCH_TRAP'
#define CATCH_TRAP() asm("int $3\n" : : ) /* NOLINT */
^
:1:2: note: instantiated into assembly here
int $3
^
1 error generated.
make[5]: *** [tests/CMakeFiles/test_catch.dir/test.cpp.o] Error 1
make[4]: *** [tests/CMakeFiles/test_catch.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [GSL/src/GSL-stamp/GSL-build] Error 2
make[1]: *** [CMakeFiles/GSL.dir/all] Error 2
make: *** [all] Error 2

The plug-in is not supported on ARM CPUs unfortunately, but neither is Maya at the moment I think.
So on an ARM machine, you will need to target the x64 instruction set.
I don’t know anything about a Mac, but you could try opening a terminal under Rosetta and then try building the plug-in?
https://www.bigbinary.com/learn-rubyonrails-book/setting-up-mac

I enabled install-rosetta with the softwareupdate command and then set Terminal to use Rosetta.
However, the build result seems to be the same.

Unfortunately I don't have a MacBook Pro M1, so it is difficult to help you. You may always send me one of course, pun intended ;-)
So I can only Google around, guessing.
E.g. maybe this thread helps:
https://discourse.cmake.org/t/how-to-determine-which-architectures-are-available-apple-m1/2401


not sure of to proceed with image size

TypeError: Parameter "imgSize" value "huge|large|xlarge|xxlarge" is not an allowed value in "['imgSizeUndefined', 'HUGE', 'ICON', 'LARGE', 'MEDIUM', 'SMALL', 'XLARGE', 'XXLARGE']"
I get this exception, by following the documentation and writing this as search params :
        _search_params = {
            'q': f"{artist_name}",
            'num': 1-10,
            'safe': 'off',
            'fileType': 'jpg|png',
            'imgType': 'face|photo',
            'imgSize': 'huge|large|xlarge|xxlarge'
            }

Can you point out what's the problem here ?
Thanks !

Hi @chromafunk ,
You can use only one image size per request, like this: 'imgSize': 'huge'.
Meaning, you can't use multiple image sizes separated with pipe.
I used pipe sign only to list all possible sizes allowed to use. Same goes for fileType and imgType.

Actually I did take a look at the tests before you answered and tried with a single value but it still threw an error. I will try again and get back to you. Thanks !


In version 0.0.2 having duration greater than 30 causes progress to step back

I ran 60s generation in 0.0.2, and i noticed progressbar going back and forth. It went to 1503 (halfway / 30s mark) then stepped back to 901 and continued until 2403 and finished (same issue with padding as well having 3 steps more than it should be)

sorry about that, thanks for reporting. sadly this probably won't get fixed soon, as this is rather low pri and we have new projects to work on !

It's ok. I love the project and I do wait for more ;)


fix: YDB-2622 remove unneeded titles

Closes https://github.com/ydb-platform/ydb-embedded-ui/issues/1506

Let's not link internal issues to external PRs, fix: remove unneeded titles will be just fine. Instead, you can mention this PR in YDB-2622 ticket


Adding a check to find NPN-capable OpenSSL.

Several comments:
-) We're always going to try building the embedded OpenSSL if we have it and if the system one isn't ALPN-capable.
-) I've removed the hardcoded test for the version number: this seems irrelevant now, especially since we have another check elsewhere that ensures the version of the submodule (which was the reason for that test to begin with).

I've done the 0.9 backport in jboeuf/grpc#1, targeting #2176.

Just to make sure. Do you want me to add it to #2176?

travis is red for a makefile generation issue. I'll merge when it's green.

Crap, I didn't realize this still wasn't merged. And here I was, telling people around me this was done. I'm a bad person.
PR has been updated.

Also, @murgatroid99, have a quick look at the Makefile changes ?

happy to merge but travis python is red. @nathanielmanistaatgoogle do you think it's a flake?

Travis is all green now btw :-P


BrowserSource size not accurate until source loads

BrowserSources let you specify a width and height to initialize at, but this is not realized by its scene items until the actual page that the browser source contains is loaded. Not quite sure how to detect if the browser is loaded or not.
I think a reasonable workaround is to include a caveat in the documentation that stats that BrowserSource properties will not be accurate on initialization. Shitty DX but I can't think of a better solution as of yet.
For a moment I thought that setSettings should be called when the source is created, thus assigning the proper sourceWidth and whatnot but this doesn't happen for two reasons: 1. CreateSource takes settings as an argument, so setSettings is not necessary, and 2. The SceneItem that ends up in itemInstances isn't created until after the CreateSource request is executed.

New implementation uses a custom BrowserSceneItem that calls updateSizeFromSource in its constructor. This sets the item's width and height based on the values passed into settings, however if no width or height is specified then they will still be zero. This is unlikely, though, since if a width and height are not applied then the source won't be visible anyway.


remove non core models/macros

Removes evm models & macros
Removes deploy evm
Removes mapping tables

Closing in favor of https://github.com/FlipsideCrypto/livequery-base/pull/1


[Feat] Add Deployment preview

firebase allows Deployment preview for each PR, before merging to our main branch
https://firebase.google.com/docs/hosting/github-integration

Hey @yuvalbl,
Here what need to do:

run on terminal this command: firebase init hosting:github
then follow this instruction:

Are you ready to proceed? - write y
For which GitHub repository would you like to set up a GitHub workflow? (format: user/repository) - write hasadna/anyway-newsflash-infographics
Set up the workflow to run a build script before every deploy? - write y
 What script should be run before every deploy? - write npm ci && npm run build
Now, if you get this line, you can rewrite the file:  GitHub workflow file for PR previews exists. Overwrite? firebase-hosting-pull-request.yml

After this, you will initial firebase preview deployment.
open the new yml file, and past those lines:

name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
    build_and_preview:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2

            - name: Setup Node
              uses: actions/setup-node@v2
              with:
                  node-version: '14'

            - run: npm ci
            - run: npm run build

            - name: Deploy
              uses: FirebaseExtended/action-hosting-deploy@v0
              with:
                  repoToken: '${{ secrets.GITHUB_TOKEN }}'
                  firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_... }}'  // Change it to what you get in initial yml file
                  projectId: ....  // Change it to what you get in initial yml file

Done in #811


update integrations user configs

Generate user configs for existing service integrations: datadog, kafka_connect, kafka_logs, metrics
Add new service integrations: clickhouse_postgresql, clickhouse_kafka, clickhouse_kafka, logs, external_aws_cloudwatch_metrics

tests https://github.com/aiven/aiven-operator/actions/runs/4233693093

For the history: I tried to add validation rule for config properties (once set can't be unset) to emulate immutability for ServiceIntegrationSpec, this is what I got:
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[6].rule: Forbidden: estimated rule cost exceeds budget by factor of more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and maxLength where arrays, maps, and strings are declared)
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[7].rule: Forbidden: estimated rule cost exceeds budget by factor of more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and maxLength where arrays, maps, and strings are declared)
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[8].rule: Forbidden: estimated rule cost exceeds budget by factor of more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and maxLength where arrays, maps, and strings are declared)
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[0].rule: Forbidden: contributed to estimated rule cost total exceeding cost limit for entire OpenAPIv3 schema
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[1].rule: Forbidden: contributed to estimated rule cost total exceeding cost limit for entire OpenAPIv3 schema
* spec.validation.openAPIV3Schema.properties[spec].x-kubernetes-validations[2].rule: Forbidden: contributed to estimated rule cost total exceeding cost limit for entire OpenAPIv3 schema

Turns out there is a budget for validation rules.


a Localizations ancestor was not found

When I try to render my flow screen with localization by DavinciCapture.offStage. I end up with error
======== Exception caught by widgets library =======================================================
The following assertion was thrown building PrintPreviewFlow(dirty):
a Localizations ancestor was not found
'package:flutter/src/widgets/localizations.dart':
Failed assertion: line 509 pos 12: 'scope != null'

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=2_bug.yml

I'm using flutter_localizations for localizations

@Misioka Thanks for filing an issue. Could you please provide, reproducible code?


Why are the results of the predictions in order

When using SAM to segment masks, multi-outputs are always in order of subpart, part and whole. I don't know how to do it even after reading the paper. Which part of training make this effect?

same question here


How Long can the Token be used until it can be refreshed.

So, I'm using this fantastic command-line tool in a project where time is of the essence, and hence we need to upload all of the files and then delete them from our server. My question is when is this token going to expire.

Thanks for your feedback @OttomanZ !
Before executing any command (like uploading a file), the tool checks if the access token needs to be renewed. If this is the case, it uses the refresh token to renew it. Afterwards, the actual command is executed. The access token expires after 60 minutes according to Microsoft's docs.
So, if you're using a shell script with a loop to upload the files, and upload one file at once, you should not run into issues. However, try and validate this before actually deleting the files from the server.

Thanks.


Crash on startup.

It just crashes on start, I don't know why.

Is there a solution for this that I don't know if? If you need more info just ask, though I'm pretty sure you will need it.

Version is all of them, even the newer releases, done on latest release but it works on every release I've tested so far.

...try going to "%APPDATA%\Minecraft_Note_Block_Studio" (copying that into the file explorer) then open the "settings.ini" using notepad and add acrylic="0" in a new line under the [preferences] tab

...go to the program's data folder (C:\Users\<username>\Minecraft Note Block Studio\Data), ... try deleting both Wallpaper files

Two solutions from the Discord server

That first one fixed it, thank you for that. Sorry for wasting the time of everyone who read this.

You can close the issue if it's resolved


specific smtp of alias

Hi all and thanks very much for this nice app
I have a professionnal address link to a personnal adrdess. Basically the professionnal address forward the email to the personnal one. However to answer to the professionnal address I must go through a specific smtp which is different from the one of the personnal address.
I have created an identity with the personnal account and an alias with the professionnal account.
Is there a way to specify the smtp of the alias?
Android version: 6.0.1
Account type IMAP:

See #1117


tsp, simplify BinaryData serialization

code https://github.com/Azure/autorest.java/commit/367bb657bf5e7a45fecc8ea2a02033a75db49805
We had existing serialization tests like https://github.com/Azure/autorest.java/blob/main/typespec-tests/src/test/java/com/cadl/union/UnionTests.java and cadl-ranch tests
also fixed a minor issue about MapType of javadoc https://github.com/Azure/autorest.java/commit/95f8fa3dfea482af14cb4711f6f8049f357dacff

simplify BinaryData serialization -> this part is only refactoring, no output code change?

Generate code changes (the function should be same)
e.g. https://github.com/Azure/autorest.java/pull/2466/files#diff-e86963be384d9d1145214ff52b355aaf867d6eaa0eea413ddc0befe761d44482


Fix service integration removal on uninstall

Problem

It was broken

Solution

I fixed it

PR Status

[x] Code finished.
[ ] Tested with Package_check.
[ ] Fix or enhancement tested.
[ ] Upgrade from last version tested.
[x] Can be reviewed and tested.

!testme


Remove unused "passwordsent" action on Security admin

This is just a bit of tidyup - I noticed the passwordsent action is still in $allowed_actions in Security but there's no corresponding action. It used to be there in CMS 3 but has since been moved as a sub-action of lostpassword (i.e. you go to /Security/lostpassword/passwordsent now).
Since there's no action corresponding to the allowed_actions config we should just remove it from there to avoid unexpected behaviour.
PRs

https://github.com/silverstripe/silverstripe-framework/pull/10672

Linked PR has been merged


Add deeplink for messages

Overview
Adds deeplink support for messages, leaving the door open to easily add other functionality. Example:
open 'goofy://message?id=FACEBOOK_ID`

Fixes https://github.com/danielbuechele/goofy/issues/417

Oops sorry I messed your PR when I refactored, but I've added, tested and committed your code by hand so should be in v3.4.1 (check out comment in #417).


Glossary View OMAS - client added

Signed-off-by: Liviu Popa<EMAIL_ADDRESS>

Corrected code based on previous observations, but I have also introduced some small modifications:

setting the type returned to 'ExternalGlossaryLink', since it was not being returned by targeted calls
extracted fields to classes for better readability and access to logic
pom updates
renamed some classes for consistency
simplified exception handling
java doc update
code improvements as a result of sonar scan


change the color of the handles border

i want to change the color of handles border

i checked in "renderScene.ts" file but no luck. i think its related to the theme.. so i checked in the "theme.scss" and nothing there also.
i'm new to TS.. so any help will be appreciated!

Here is where local user color could be updated https://github.com/excalidraw/excalidraw/blob/master/src/renderer/renderScene.ts#L314 in case you are forking the repo.
For remote users, you can call updateScene and pass collaborators
Whats your use case ? We could support updating local user color as well via the API, so you don't have to fork the repo

Here is where local user color could be updated https://github.com/excalidraw/excalidraw/blob/master/src/renderer/renderScene.ts#L314 in case you are forking the repo.
For remote users, you can call updateScene and pass collaborators
Whats your use case ? We could support updating local user color as well via the API, so you don't have to fork the repo

i tried to change the color to :
selectionColors.push(oc.green[6]);
and nothing changed, the border stayed black. am i doing something incorrect?
thank you

i tried to change the color to :
selectionColors.push(oc.green[6]);
and nothing changed, the border stayed black. am i doing something incorrect?
thank you

@zsviczian please check this.. any help will be appreciated!
thank you

@zsviczian please check this.. any help will be appreciated!
thank you

i tried to change the color to : selectionColors.push(oc.green[6]); and nothing changed, the border stayed black. am i doing something incorrect? thank you

can you share your code ? Updating https://github.com/excalidraw/excalidraw/blob/master/src/renderer/renderScene.ts#L314 will update the selection color to green

Whats your use case ? We could support updating local user color as well via the API, so you don't have to fork the repo

i'm talking about the "handles borders" the squared used fo resizing

@ad1992 have you find a way? thank you

i found it , i added this line:
context.strokeStyle = "#fff";
after context.save(); line 200 in "renderScene.ts"


Bugfix/unknown layer

added default-naming for unknown layer types

Codecov Report

Merging #34 (bb6fe08) into main (8d81d41) will decrease coverage by 0.68%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main      #34      +/-   ##
==========================================
- Coverage   89.83%   89.14%   -0.69%
==========================================
  Files          20       20
  Lines        1407     1410       +3
==========================================
- Hits         1264     1257       -7
- Misses        143      153      +10

Impacted Files
Coverage Δ

...a_toolbox/encodings/pytorch/ingest_architecture.py
84.78% <50.00%> (-1.15%)
:arrow_down:

rfa_toolbox/domain.py
72.72% <0.00%> (-13.64%)
:arrow_down:

rfa_toolbox/encodings/pytorch/domain.py
62.50% <0.00%> (-12.50%)
:arrow_down:

...olbox/encodings/tensorflow_keras/layer_handlers.py
90.90% <0.00%> (-4.55%)
:arrow_down:

tests/test_encodings/test_pytorch.py
98.24% <0.00%> (-1.76%)
:arrow_down:

Continue to review full report at Codecov.

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


Test with max procs enabled

:construction:

Codecov Report
Patch coverage has no change and project coverage change: -49.11 :warning:

Comparison is base (f3f2ca8) 57.65% compared to head (c157988) 8.54%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #2200       +/-   ##
==========================================
- Coverage   57.65%   8.54%   -49.11%
==========================================
  Files         182      95       -87
  Lines       15207   10707     -4500
==========================================
- Hits         8767     915     -7852
- Misses       5271    9737     +4466
+ Partials     1169      55     -1114

Flag
Coverage Δ

acceptance-api
?

acceptance-apps
?

acceptance-cli
?

unittests
8.54% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 165 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Settings sync not working in Linux

Type: Bug

Press the user icon at the bottom left corner
Press "Turn settings sync on"
Login with Microsoft or GitHub
After a few seconds you'll get a popup error aboy sync telling you that something went wrong, on the output log there is:

[2022-10-19 11:14:51.307] [settingssync] [info] Sync started.
[2022-10-19 11:15:59.581] [settingssync] [info] Did reset the local sync state.
[2022-10-19 11:15:59.623] [settingssync] [info] Settings: Not synced yet. Last sync resource does not exist.
[2022-10-19 11:17:30.811] [settingssync] [info] Request failed https://vscode-sync.trafficmanager.net/v1/resource/settings/latest

It won't sync settings
VS Code version: Code 1.72.2 (d045a5eda657f4d7b676dedbfa7aab8207f8a075, 2022-10-12T22:16:26.920Z)
OS version: Linux x64 5.15.0-50-generic
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz (20 x 1000)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
2, 2, 2

Memory (System)
23.31GB (14.38GB free)

Process Argv
--unity-launch --crash-reporter-id fcae088a-f527-42b9-8e8f-04300a6091ac

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Extensions: none
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
i497e931:30553904
pyindex848cf:30577861
nodejswelcome1cf:30587006
40g7c324:30573242

Can you please share the network requests from F1 > Developer: Toggle Shared Process ?

Can you please try again and let us know if you are still reproducing this? We made some recent improvements to Settings Sync server to scale up. If you see the errors, please share the settings sync log. Thanks.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Upload failure on CircleCI

So, this is a fun issue. Looks like it failed to upload. Seems like an anaconda-client issue ( https://github.com/Anaconda-Platform/anaconda-client/issues/335 ) cropped up after some sort of failure to upload. See this log and the traceback below.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.5/site-packages/binstar_client/commands/upload.py", line 214, in main
    callback=upload_print_callback(args))
  File "/opt/conda/lib/python3.5/site-packages/binstar_client/__init__.py", line 500, in upload
    raise errors.BinstarError('Error uploading package', s3res.status_code)
binstar_client.errors.BinstarError: ('Error uploading package', 500)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/conda/bin/anaconda", line 6, in <module>
    sys.exit(binstar_client.scripts.cli.main())
  File "/opt/conda/lib/python3.5/site-packages/binstar_client/scripts/cli.py", line 87, in main
    description=__doc__, version=version)
  File "/opt/conda/lib/python3.5/site-packages/binstar_client/scripts/cli.py", line 66, in binstar_main
    return args.main(args)
  File "/opt/conda/lib/python3.5/site-packages/binstar_client/commands/upload.py", line 219, in main
    except requests_ext.OpenSslError:
TypeError: catching classes that do not inherit from BaseException is not allowed
Traceback (most recent call last):
  File "/feedstock_root/ci_support/upload_or_check_non_existence.py", line 124, in <module>
    main()
  File "/feedstock_root/ci_support/upload_or_check_non_existence.py", line 108, in main
    upload(cli, meta, owner, channel)
  File "/feedstock_root/ci_support/upload_or_check_non_existence.py", line 55, in upload
    env=os.environ)
  File "/opt/conda/lib/python3.5/subprocess.py", line 584, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['anaconda', '--quiet', '-t', 'binstar.token', 'upload', '/feedstock_root/build_artefacts/linux-64/gmpy2-2.0.7-py34_0.tar.bz2', '--user=conda-forge', '--channel=main']' returned non-zero exit status 1

cc @pelson

Going to try restarting the build to see if this wasn't a fluke.

Sure enough. Restarting fixed the issue. Closing...


Tune Aquavanjaram942 Grid sizes for BBS NN

Updated 8 grid points to address perf tuning request.
Ensure changes doesn't degrade existing grid point performance.

If this PR is necessary for 6.3, please remember file PR to release-staging/rocm-rel-6.3 as well.

Please run hipblaslt-test on your local node (with the change) and paste the result here if you put noCI label.

[----------] 1 test from ExtOpTest/ExtOpAMaxWithScaleUnsupportedDatatypeTest
[ RUN      ] ExtOpTest/ExtOpAMaxWithScaleUnsupportedDatatypeTest.amaxWithScaleFailureUnsupportedDatatype/0
[       OK ] ExtOpTest/ExtOpAMaxWithScaleUnsupportedDatatypeTest.amaxWithScaleFailureUnsupportedDatatype/0 (0 ms)
[----------] 1 test from ExtOpTest/ExtOpAMaxWithScaleUnsupportedDatatypeTest (0 ms total)
[----------] Global test environment tear-down
[==========] 48206 tests from 13 test suites ran. (2234494 ms total)
[  PASSED  ] 48206 tests.
hipBLASLt version: 1000
command line: ./hipblaslt-test

Don't we need to cover HHS?

Don't we need to cover HHS?

Yes the request is for both HHS and BBS. Planning to address it as a separate PR.