typeahead: Add typeahead for slash commands.

This is the follow-up of PR #10267.
Here, we add typeahead for slash commands in compose box. We exclude "/day"
and "/light" if you're in day mode already, and we exclude "/night" and
"/dark" if you are in night mode.
The slash typeahead will open only when / is the first character. This
also adds a description of what the slash command does in the typeahead.

This is the follow up of PR#10267, I found I need to rework after playing several times with rebasing-stashing-conflicts... So did a soft reset and stashed them and did a complete rework on top of that stash at latest master. And rather than two separate commit I found single commit made more sense, but I could split them into two if needed.
As you mentioned in https://github.com/zulip/zulip/pull/10267#issuecomment-412695268, following changes were made :

Added the description text in the typeahead.
Also, it now has the correct white space behaviour for slash
commands i.e leave a space after we complete them (eg. /me ).
I haven't made the sort function for slash commands because for now, I don't feel it is needed to be sorted, but maybe in future, when we add more slash commands we'll need it, so will add sorter in a separate commit soon.

And for your sorting the content part, I think we need it now as you can see in the GIF below:

I'll like to know what strings should we use as slash commands description, I've given some description temporarily. And currently, tests are failing due to capitalization issues, once we finalize the strings, I'll change accordingly.

So, in terms of what's actually useful to have in the typeahead:

I think /ping is probably mostly useless and we should not include in typeahead (it, like /night and /settings, was basically a demo feature)
The main actual feature we care about typeahead for is /poll, but we want to have reasonable infrastructure for doing other things down the line.

So I think it might be best to recast this PR as just /poll and /me.  We can do as follows:

/me is excited (Display action text)
/poll Where should we go to lunch today? (Create a poll)

I've updated the PR, now this includes :

A basic sorter function for slash commands has been added in a separate commit, later we'll see whether we need to include any other complications with this.
A separate commit for removing the unnecessary string operations has been added as mentioned by @shubhamdhama .
Only /poll and /me are included in the typeahead and suggested description text has been added.
@timabbott FYI.

There's one major change to the UI I'd like to see here, which is that we should pop the typeahead when you just type / at the start of a message, with no other characters; I think that'll help a lot with discoverability.

For sorting, why is prefix_sort not all we need here?

I've updated the PR with UI change so that when we type /, all slash commands are displayed.
@shubhamdhama It would be great if you could review the changes.
Tim, For the current two typeahead, prefix_sort is enough, but I made it more generic and added a slash_command_comparator function keeping in mind that maybe in future we'll be adding more slash commands typeahead and thus it would be useful then.
@timabbott FYI.

Merged as the commits ending with a2a86eac3f604a6b703e1a6045c6c58c7b63d7e9, after adding some comments, fixing a typo in the name of slash_command_comparator, and replacing the commit message of 2e67cf38b379bd30997791fcceec53407daa0cb1 with something that explains the reasoning for why it's not a regression.  Thanks @pragatiagrawal31!


cmd/compile: optimize recursive closure calls

It is often convenient to define recursive functions local to some outer function, either because you don't want to pollute the package namespace with helper functions, or because the recursive function wants to close over locals of the outer function. Of course Go doesn't have recursive function literals so you have to fake it by using the var trick. The escape analysis is smart enough to avoid heap-allocating the closure in such cases, but unfortunately the actual recursive call is still dynamic.
type Cell struct {
	Next *Cell
}

func f(c *Cell) {
	var visit func(c *Cell)
	visit = func(c *Cell) {
		if c.Next != nil {
			visit(c.Next) // generates CALL (R1) on ARM
		}
	}
	visit(c)
}

Could the compiler be made smart enough to notice that the visit variable is assigned exactly once to a func literal, and thus it is safe to turn the whole thing into a letrec so that the call to visit becomes static?

Yes, I think this is doable.
What's the end goal? To just replace the dynamic call with a static call? Or to know the callee for escape analysis? For the former, it should be pretty easy to do in SSA. But I'm skeptical just changing the call from indirect to direct will save much time. The latter might be much more helpful but that means we have to do it earlier in the compiler, which is more difficult.

What's the end goal?
I'm skeptical just changing the call from indirect to direct will save much time.

I keep seeing recursive calls as hotspots in profiles and I wanted to avoid the dynamic call overhead, but I just benchmarked it below (on an M1) and as you predicted, it didn't show a great deal of gain: only about 0.6ns per call. Is that a sign that the M1's branch and return prediction is really good?

Or to know the callee for escape analysis? For the former, it should be pretty easy to do in SSA. The latter might be much more helpful but that means we have to do it earlier in the compiler, which is more difficult.

Well, synergy is good. It shouldn't be that hard to detect the pattern during the traversal over typed syntax: you have a var, a single assignment from a literal, and a body that only references the var in function call position.
But the contribution to the profile is less than I expected.
$ cat virt/virt_test.go
package virt_test

import "testing"

type Cell struct {
	Next *Cell
}

var theList *Cell

func init() {
	var c *Cell
	for i := 0; i < 16; i++ {
		c = &Cell{c}
	}
	theList = c
}

func BenchmarkDynamic(b *testing.B) {
	var visit func(c *Cell)
	visit = func(c *Cell) {
		if c.Next != nil {
			visit(c.Next) // dynamic call
		}
	}

	for i := 0; i < b.N; i++ {
		visit(theList)
	}
}

func BenchmarkStatic(b *testing.B) {
	for i := 0; i < b.N; i++ {
		visit(theList)
	}
}

func visit(c *Cell) {
	if c.Next != nil {
		visit(c.Next) // static call
	}
}
xtools$ go test -bench=. ./virt
BenchmarkDynamic-8   	53538361	        22.34 ns/op
BenchmarkStatic-8    	93342842	        12.85 ns/op

cc @golang/compiler

Another benchmark comparing (a) a closure and dynamic call with (b) a non-closure with explicit parameter. The difference is about 1ns per call, or about 22% of the recursion cost. (Changing the Anon variant to put 'total' in the closure instead of a parameter adds +2%.)
package recursion_test

import "testing"

type Tree struct {
	Left, Right *Tree
	Value       int
}

const N = 10

var root = makeTree(N)

func makeTree(depth int) *Tree {
	if depth == 0 {
		return nil
	}
	return &Tree{
		Left:  makeTree(depth - 1),
		Right: makeTree(depth - 1),
	}
}

// -- recursion using anonymous function --

func BenchmarkAnon(b *testing.B) {
	for range b.N {
		sum := SumAnon()
		if sum != 1<<N-1 {
			b.Fatal("oops", sum)
		}
	}
}

func SumAnon() (total int) {
	// sum is a closure, but its only free variable is 'sum'
	var sum func(t *Tree, p *int)
	sum = func(t *Tree, p *int) {
		if t != nil {
			*p++
			sum(t.Left, p)
			sum(t.Right, p)
		}
	}
	sum(root, &total)
	return
}

// -- recursion using named function --

func BenchmarkNamed(b *testing.B) {
	for range b.N {
		sum := SumNamed(root)
		if sum != 1<<N-1 {
			b.Fatal("oops", sum)
		}
	}
}

func SumNamed(t *Tree) (total int) {
	sumNamed(t, &total)
	return
}

func sumNamed(t *Tree, p *int) {
	if t != nil {
		*p++
		sumNamed(t.Left, p)
		sumNamed(t.Right, p)
	}
}

xtools$ go test -bench=. ./bench_test.go
goos: darwin
goarch: arm64
BenchmarkAnon-8    	  295784	      4061 ns/op
BenchmarkNamed-8   	  375530	      3187 ns/op


TODO: Remove unsafe and development-unfriendly _G

_G metatable can be detected in some executors, and even if it can't, it's still not a direct replacement to locals or globals since you still have to explicitly specify that the object is in _G. most executors have getgenv() now, which is both safe to use and a drop-in-replacement for global objects, meaning ambiguous syntax but higher priority for the global environment.

we should probably use shared. it's not detectable like _G, acts the same as getgenv(), but it's supported on every single executor

thought shared was exactly the same as _G

:trollface:


feat: introduce new infix operators

Just made a PR with the proposed symbols. The old ones are deprecated. @mikeshulman @jonsterling Closes #12.

<: for "snoc": Emp <: 1 <: 2 <: 3.
Previously, it's #<.
<@ for append: Emp <@ [4; 5; 6] <@ [7; 8; 9].
Previously, it's <><.
@> for prepend: b1 @> b2 @> [10].
Previously, it's <>>.

Question: Should we keep mentioning Conor McBride for the new symbols?

Maybe also update the example in the README?


Implement extra traits for all types

Now that I've gotten all the extra traits implemented for libc, they can be easily derived for nix's types. Note that this requires a bump to the minimum supported Rust version, but it's still at least 2 versions behind, so it fits in with policy.
One thing I did notice is that we have an inconsistent approach to our newtypes, where some use a struct and some a tuple struct. We should be consistent here, and should probably use a tuple struct since the name of the single field is irrelevant. This style is already suggested in our CONVENTIONS.md doc, so this should be uncontroversial. I'll file a PR after this is merged adding that.

Would it be possible to split out just the Debug portion of this PR if the rest of the traits are blocked on upstream libc?

Now that rust-lang/libc#1371 was merged, it's time to come back to this. That should have resolved most of the issues. Gonna test this through CI then do another pass through @asomers' comments.

Sorry I wasn't clear. I was planning to write new tests. The problem is that I dont know how to write them. I can handcraft sockaddr_un structs to test equality, but that seems like I'm coding the same logic in the test and I'm testing for and I dont think it'll provide much value. Or I can modify the stack so that all values are nonzero and use UnixAddr directly to do the comparison. I think the latter would be a better implementation, but I don't know how to do it.
On Wed, Jun 5, 2019, at 8:44 AM, Alan Somers wrote:

@asomers commented on this pull request.

In src/sys/socket/addr.rs https://github.com/nix-rust/nix/pull/1035#discussion_r290808764:

@@ -687,27 +595,6 @@ impl UnixAddr {
}
}

-impl PartialEq for UnixAddr {

fn eq(&self, other: &UnixAddr) -> bool {

   self.sun_path() == other.sun_path()

Yeah, we should definitely be testing equality for abstract sockets. I would suggest just manually creating some so we can get all of the edge cases.

Turns out we have some tests that check the paths for regular and abstract sockets. I was thinking of extending them, but I'm not certain the right way to do it. I was going to create a u8 array of 0xFF the same size of the struct, transmute it to a UnixAddr and then manually set the sockaddr_un and usize fields. This will have a bunch of custom logic to set those fields the way I think they should be set.

What I would prefer to do is to initialize a UnixAddr, then set the stack to contain 0xFF for a large chunk of memory, and initialize an identical UnixAddr, and then compare them for equality and hashing. That should test it very effectively and remove all of the complexity of stuffing data in correctly by hand. Do you know of a way to do that with Rust?

That sounds cumbersome. Instead of modifying those tests, why not write new tests directly in src/sys/socket/addr.rs? That way you'll be able to access the underlying libc::sockaddr_un directly.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/nix-rust/nix/pull/1035?email_source=notifications&email_token=AABSMG6FAYL5OK7OTNJEAMLPY7NMTA5CNFSM4G45KN3KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB2VR72Q#discussion_r290808764, or mute the thread https://github.com/notifications/unsubscribe-auth/AABSMG45V2F4H7YQCNPJJUTPY7NMTANCNFSM4G45KN3A.

Sorry I wasn't clear. I was planning to write new tests. The problem is that I dont know how to write them. I can handcraft sockaddr_un structs to test equality, but that seems like I'm coding the same logic in the test and I'm testing for and I dont think it'll provide much value. Or I can modify the stack so that all values are nonzero and use UnixAddr directly to do the comparison. I think the latter would be a better implementation, but I don't know how to do it.

I think the most straightforward way would be to handcraft a libc::sockaddr_un, cast to a libc::sockaddr_storage, convert to a UnixAddr via sockaddr_storage_to_addr, then compare UnixAddrs.  That way you'll have byte-level control of the data using only the regular API.

Alright, I implemented something that I think is a reasonable test. Tests passed on my local computer, so if CI passed, I think this is good to go.

Looks like PTRACE_ATTACH was changed in a commit at some point I guess and now it can't be found for mips64 targets. However, I'm not finding anywhere where that changed in libc or nix. So that's it for me tonight, I'll need to come back and dig in to it again later.

Looks like PTRACE_ATTACH was changed in a commit at some point I guess and now it can't be found for mips64 targets. However, I'm not finding anywhere where that changed in libc or nix. So that's it for me tonight, I'll need to come back and dig in to it again later.

Yeah, that one stumped me too.  I installed the exact mips64 target for the 1.24.1 toolchain and checked that I'm building against the exact same revision of libc as Travis used, but for me it works.

Figured out I wasn't synced to HEAD and 4bd419ebec2d691f55331e91e799d5fa96180044 was the problem. Filed rust-lang/libc#1393 to resolve.

Alright, looks like we should be all good to go here now that my LINC PR was merged!

Alright, I think we're all good with this one. Libc changes have all been merged and tests are all padsing

Hopefully this is the final necessary batch of changes!


[macos] add retries to chrome install script

Description
add retries to chrome install script
Related issue:
Check list

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

abandon in favour of https://github.com/actions/runner-images/pull/8639


tile-join does not remove attribute

Using the following command does not remove the "name" attribute from my mbtile.
tile-join -x name -o new-filename old-filename

Can you provide a more detailed example of what is failing? If I do
$ ./tippecanoe -f -o foo.mbtiles tests/ne_110m_populated_places/in.json
$ ./tippecanoe-decode foo.mbtiles | grep FEATURECLA | head -2
$ ./tile-join -f -x FEATURECLA -o bar.mbtiles foo.mbtiles
$ ./tippecanoe-decode bar.mbtiles | grep FEATURECLA

the FEATURECLA attribute is removed from the second-stage bar.mbtiles as intended. I'd like to understand what is happening differently for you.

Using tippecanoe-decode, I noticed that there was a \u000d character after the attribute name. The csv file from which the attribute originated was generated in Windows. Once I converted the line endings in the csv file to UNIX format and re-imported the attributes, the extra character was no longer there and I was able to remove the attribute successfully.

Thanks. I should filter out \r since other people will probably have files from Windows with the same problem, and there's no reason to treat it as significant.

This will be fixed in https://github.com/mapbox/tippecanoe/pull/336


flutter-engine arm64 host support

-flutter-engine arm64 host support
-ivi-homescreen roll
-pdf demo RDEPENDS

Passes building flutter-gallery on Mac M2 -> UTM virtualization -> Ubuntu 22
I'm building a rpi-zero2w-64 image based on this CI job (with my updated meta-flutter branch):
https://github.com/meta-flutter/meta-flutter/blob/kirkstone/.github/workflows/kirkstone-rpi-zero2w-64.yml

flutter-gallery builds (flutter-sdk-native, flutter-engine)
ivi-homescreen builds
flutter-auto builds
flutter-pi builds
flutter-rust-bridge-example builds
audioplayers example builds.  including flutter-gallery that covers all the flutter-apps.
zenity builds (file selector)
dart-sdk builds (tested with meta-clang)
firebase-cpp-sdk fails (no module named absl)
sentry build fails (QA -dev package issue)
pdfium fails fetching .cip pacakge - later

Some recipes have not been tested for parity with x86_64 builds.


Adding the Direct2D ImageBrush

The ImageBrush is able to be draw any kind of image (or just a part of it? and maybe scaled?) into any shape you chose.
Example: Render an image in the shape of a circle and cut of everything thats outside of it.

DrawImage doesn't support transparency. did you test that ?
I used this code & SharpDX DrawBitmap Method. but this doesn't support windows 7 PixelFormat.
public static SharpDX.Direct2D1.Bitmap CreateBitmap(this Graphics gfx, byte[] res)
       {
           SharpDX.WIC.ImagingFactory imagingFactory = new SharpDX.WIC.ImagingFactory();
           System.IO.MemoryStream fileStream = new System.IO.MemoryStream();
           fileStream.Write(res, 0, res.Length);

           SharpDX.WIC.BitmapDecoder bitmapDecoder = new SharpDX.WIC.BitmapDecoder(imagingFactory, fileStream, SharpDX.WIC.DecodeOptions.CacheOnDemand);
           SharpDX.WIC.BitmapFrameDecode frame = bitmapDecoder.GetFrame(0);

           SharpDX.WIC.FormatConverter converter = new SharpDX.WIC.FormatConverter(imagingFactory);
           converter.Initialize(frame, SharpDX.WIC.PixelFormat.Format32bppPRGBA);

           var newBitmap = SharpDX.Direct2D1.Bitmap1.FromWicBitmap(gfx.GetRenderTarget(), converter);
           fileStream.Close();

           return newBitmap;
       }

       public static void DrawBitmap(this Graphics gfx,SharpDX.Direct2D1.Bitmap bitmap, SharpDX.Mathematics.Interop.RawRectangleF rec ,float opa = 1.0f)
       {
           gfx.GetRenderTarget().DrawBitmap(bitmap, rec, opa, SharpDX.Direct2D1.BitmapInterpolationMode.Linear);

       }


Stack using Queues | C

Stack using Queues
what will change -
I’d like to add a stack implementation using queues in C language under data structures.
Type of Issue -

[x] Adding New Code

Programming Language

[x] C

Self Check

Ask for issue assignment before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Happy Coding!

@Aron-R can you please assign it to me ?

@Aron-R can you please assign it to me ?

I don’t think I can assign this to anyone, The CONTRIBUTIONS.md file said that if I thought something is missing, I can create an issue and so I’ve created an issue and if they happen to assign it to me I would work on it


Resample function optimizations

Currently it takes me quite a long time to carry out a resample function. I've got about 120 channels with about 10 minutes of data, sampled at 5Khz, which equals about 120 x 3,000,000 data points. Obviously my first step in this process is to resample the data such that it's not so densely-sampled. However, this can take a really long time and use a lot of memory.
I have two questions regarding this:

Is the resampling optimized at all in terms of making sure that the signal is a ^2 in length? In the past I've tried to pad the signal with 0's to the next pow2, but this can be a memory issue if there are enough datapoints. Another option is to find a close number with lots of factors, no?
What kind of speedup do you all see when you use CUDA? Is it worth the time to set up in terms of the performance boost?

Anyway just trying to see if anyone has thoughts on improving the speed of these functions. If more people use MNE that do ECoG research (and thus have little control over the recording parameters), it may prove useful.

the culprit is the resample method from scipy.signal that honestly sucks...
it does a dummy fft over the entire signal length... the problem has to be
fixed in scipy.
you might want to try: http://scikits.appspot.com/samplerate

In my experince CUDA is about an order of magnitude faster. I'm pretty sure that was both for FIR filtering and resampling. What would really help the CPU case is using upfirdn as discussed in #1814.

Yeah, the scipy signal processing is the one thing that makes me miss matlab (just a little bit). I've tried creating functions like make_len_pow_2 that just dumbly the next power of 2 and appends 0's to the signal. That definitely speeds things up, but can explode the memory. What if something like that was added to the resample function as an option to npad? So if you put in a string like 'pow2' then it would find how many datapoints to add to make it a power of 2, then split it in half and add it to the front/back of the signal?

+1 for the string idea, we already do something similar for filter lengths

Did you already begin an upfirdn contribution to scipy? That may be outside of my signal processing chops :/

No, and it's going to take some time to get right. So for now the padding to power of 2 should help.

Someone actually has a SWIG'ed version available they gave me permission to relicense as BSD for scipy, but I'm not sure how complex that problem is going to be.

Ah ok - for the resample string thing, do you know if there is a function
in python for "give me a number, and I will tell you the next highest
number with greater than N factors"? I've tried padding to a power of two,
but once you're in the higher regions it becomes memory-limited. That said,
this sounds like it may be too complicated to include natively :P.
Actually another thought might be to allow someone to specify the total
length that they want the signal to be, rather than the amount of padding.
E.g.: have some parameter length, take the diff from current length,
divide that in half, and add zeros to the front/back accordingly.
On Wed, Apr 29, 2015 at 7:00 AM, Eric Larson<EMAIL_ADDRESS>wrote:

Someone actually has a SWIG'ed version available they gave me permission
to relicense as BSD for scipy, but I'm not sure how complex that problem is
going to be.
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2035#issuecomment-97434678
.

No, I don't know of one. If memory is an issue, one thing that might fix that is iterating over channels instead of operating on them as a contiguous block (e.g., as axis=1). The overhead for a few hundred channels should be pretty negligible, but you'd want to test it to make sure.

Ya that is true - if you do it for one channel at a time it's not a big
deal, so in that case you would basically do:
  all_res_chans = []
  for chan in channels:
    chan = pad_to_power_2(chan)
    chan_res = resample(chan)
    all_res_chans.append(remove_padding(chan_res))
  make_back_into_Raw(all_res_chans)

or something like this
On Wed, Apr 29, 2015 at 9:55 AM, Eric Larson<EMAIL_ADDRESS>wrote:

No, I don't know of one. If memory is an issue, one thing that might fix
that is iterating over channels instead of operating on them as a
contiguous block (e.g., as axis=1). The overhead for a few hundred
channels should be pretty negligible, but you'd want to test it to make
sure.
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2035#issuecomment-97503588
.

Yeah, that's the pseudocode anyway. Getting it to work with the current resampling might take some work, but should be doable, at least for the n_jobs=1 case. Sometimes we branch based on whether n_jobs == 1 or not, and this would be a case where it could be useful to do so. You can't really avoid the memcpy-type operation with multiple jobs, unfortunately, so it will only work for a single-job case.
You're welcome to take a stab at it if you have time. I think if n_jobs=1 you'd want to preallocate the new array, and fill it in row-by-row by resampling.

mm that's a good idea. I will try to include this if I finish my stuff for
this week early. Have a plane flight tomorrow so maybe then.
On Wed, Apr 29, 2015 at 10:05 AM, Eric Larson<EMAIL_ADDRESS>wrote:

Yeah, that's the pseudocode anyway. Getting it to work with the current
resampling might take some work, but should be doable, at least for the
n_jobs=1 case. Sometimes we branch based on whether n_jobs == 1 or not,
and this would be a case where it could be useful to do so. You can't
really avoid the memcpy-type operation with multiple jobs, unfortunately,
so it will only work for a single-job case.
You're welcome to take a stab at it if you have time. I think if n_jobs=1
you'd want to preallocate the new array, and fill it in row-by-row by
resampling.
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2035#issuecomment-97505635
.

Hopefully I'll have time to actually make this PR work and get it into scipy:
https://github.com/scipy/scipy/pull/5186

An update -- this should be made ~2x faster in the near term (months) by https://github.com/scipy/scipy/issues/5592 and the related https://github.com/scipy/scipy/pull/5610. By my estimate, using upfirdn through https://github.com/scipy/scipy/pull/5186 will require more time (~6-12 months).

That's great - looking forward to not dreading my resampling steps :)

FYI scipy/scipy#5610 (upfirdn) has been merged and I've started a upfirdn-based resample discussion in https://github.com/scipy/scipy/issues/5746.

wohoo! wheels are a-turning :)
On Wed, Jan 20, 2016 at 10:43 AM, Eric Larson<EMAIL_ADDRESS>wrote:

FYI scipy/scipy#5610 https://github.com/scipy/scipy/pull/5610 (upfirdn)
has been merged and I've started a upfirdn-based resample discussion in
scipy/scipy#5746 https://github.com/scipy/scipy/issues/5746.
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2035#issuecomment-173320526
.

Indeed, v. cook.


Comparison with other libraries

Hi @neoziro @vvo! This library looks great - thank you for open sourcing this!
Its probably on your list, but if not, do consider providing a more indepth comparison with react-loadable, and react-async-components.
Personally, I am curious to understand if SSR is the main difference, or are there other differences, as well, as how you approach SSR differently from those libraries.
It'd be super helpful to folks, like me, trying to pick a library!
Thank you!

@oyeanuj thank you!
I tried to explain it in the readme.
I also documented how to implement a delay and how to implement a timeout.

@neoziro I saw this in the documentation.

react-loadable was the recommended way for React code splitting for a long time. However, today it is not maintained any more and it is not compatible with Webpack v4+ and Babel v7+.

I'm confused because I see commits on react-loadable, and it runs perfectly with webpack v4.
Except it is not real "open source", I'm curious to see currently any main difference from that library?
Thank you!

"Commits"

Better - compare this react-loadable fork, with react-loadable. That's the answer.

Since september, just a readme commit. Issues disabled, tons of PR not merged. For me it means « unmaitained ». It does not handle all webpack 4 stuff (agressive code splitting), it is not compatible with React Strict Mode.
Also it is just facts, if you are confident about it feel free to use it!

@oyeanuj  @theKashey  thanks!!
You're right. i didn't really pay attention to how "unmaintained" it is already.
Surely will try this library from now!


Touch up package.json, license, readme

⚠ This issue has been locked due to age. If you have encountered a recent
problem that seems to be covered by this issue, please open a new issue.
Please include a minimal reproducible example
when opening a new issue.


feat: add payment table pagination

didn't we already have pagination? what is this doing?

didn't we already have pagination? what is this doing?

it wasn't paginated on the database side, it was just the on the soft side. not sure if keeping that implementation would be a great approach

ah sure. with your update wordpress uses the server pagination automatically?

ah sure. with your update wordpress uses the server pagination automatically?

Yes, sure. now it won't have to load many records at once. will just retrieve the ones that will be displayed on a page


Use parse tree

Previously we were just using the Tokenizer from JuliaSyntax, but we might as well use the full parse-tree. It's higher-quality data, and with just a little more work we can have much more accurate highlighting.
Subject to change as I work on this, but here's a before and after screenshot for the current progress:
Before

After

Specific showcases

Beautiful :-)
The highlighting of x in the comment is particularly neat.
It makes me want to include tools - maybe even a parser mode - to further process the content of docstrings and comments within JuliaSyntax. But I know I shouldn't go there :laughing:

Thanks Claire :slightly_smiling_face:

The highlighting of x in the comment is particularly neat.

It's inspired by https://code.tecosaur.net/tec/simple-comment-markup, which I consistently find slightly nice to have.

It makes me want to include tools - maybe even a parser mode - to further process the content of docstrings and comments within JuliaSyntax. But I know I shouldn't go there 😆

Heh, yea, I can see the temptation. I'm tempted to add an ad-hoc markdown parser for docstrings.
For the future, something else I'm considering is making an extensible list of highlighting passes be used. That way DSLs introduced by macros could get custom highlighting, for instance (I'd love to see styled"..." with highlighting).
Once I've applied the tweak we discussed on slack, I'm thinking we can just merge this and improve from here. The particulars of the highlighting scheme (the faces used, and where they're applied) are explicitly mentioned as subject to change.

One point that might be an improvement: In the help, example julia> prompts are colored in green. This makes it difficult to visually distinguish from the actual prompts in the REPL history.
For this reason, OhMyREPL.jl will highlight julia> prompts in the help menu as red.
I would prefer if REPL mirrored OhMyREPL here
Current master:

1.10 with OhMyREPL:

@jakobnissen two things

I'm not sure that julia prompt highlighting should be considered by this library
The behaviour you reference is already customisable: https://github.com/JuliaLang/julia/pull/54423

a = """function foo(x::AbstractArray{<:Integer{{Bar}}, 3})\n    findfirst('z', (("happy"))) === nothing == [0x40, 0x52, 0x62, [[0x63]]] += 2\nend""" # Not intended to be real code, just to demonstrate syntax
write(stdout, JuliaSyntaxHighlighting.highlight(a))

My comments:

Parentheses/braces at highest level could have the same color as a function name/type, respectively. They're already distinct enough, so don't need to separate them with different colors.
Parentheses and brackets could alternate with two colors (light and dark versions of one) the same way you have braces now.
Consider using bright white for literals rather than a color
nothing could share the same coloring as literals
If literals are no longer purple, then alternating purple/light purple is available for brackets
Operators could have the same color as functions, except inside braces they could have the same color as types.
I don't love that the assignment operator is multicolor. I assume the intent is to make sure it's distinguishable from equality? But maybe I'll find it a good tradeoff if the other colors are smoothed out. Or maybe the whole thing could just use the red?
Commas in type signature currently has the same color as types, but commas elsewhere are the standard gray. Perhaps they should all be gray?
The in-comment blue-in-ticks should probably be dark blue to match the darker comment, otherwise the eye is drawn to it.

I've mocked up what most of my present suggestions would look like:

Alternate where the types and operators inside a type parameter also alternate so they match the next brace level:

The behaviour you reference is already customisable: https://github.com/JuliaLang/julia/pull/54423

99.9% will use defaults and will now be confused about what came from markdown rendering and what came from the actual REPL. Making the default non-confusing seems like a good idea.

Thanks for the feedback @BioTurboNick! To keep the conversation rolling, I'll lay out my initial thoughts on your comments.

Parentheses/braces at highest level could have the same color as a function name/type, respectively. They're already distinct enough, so don't need to separate them with different colors.

[behaviour] Matching parent colouring to the context seems viable, but a bit of a hassle. I'm inclined to bump that off to a future PR (possibly by someone else) even if we're sold on it.
[defaults] There is also a no-colour option available by setting JuliaSyntaxHighlighting.RAINBOW_DELIMITERS_ENABLED[] = false.

Parentheses and brackets could alternate with two colors (light and dark versions of one) the same way you have braces now.

[defaults] I think this is a question of defaults, since julia_rainbow_paren_{1-6} can be customised.
I don't mind discussion on defaults, but I would like to separate it out from discussion on the capabilities/design :slightly_smiling_face:.

Consider using bright white for literals rather than a color

[defaults] Maybe? I'm not entirely sure what defaults everybody most people would be happy with here.

nothing could share the same coloring as literals

Currently, they are? I'm assuming by literals you mean :symbols?

If literals are no longer purple, then alternating purple/light purple is available for brackets

[defaults] That's an interesting thought...

Operators could have the same color as functions, except inside braces they could have the same color as types.

[defaults] perhaps, I think this might be somewhat divisive though, IIRC a few people on slack liked it different
[behaviour] refer to earlier comments on parent highlighting matching their context

I don't love that the assignment operator is multicolor. I assume the intent is to make sure it's distinguishable from equality? But maybe I'll find it a good tradeoff if the other colors are smoothed out. Or maybe the whole thing could just use the red?

This behaviour was suggested by Fredrik Ekre: https://fredrikekre.se/posts/highlight-julia/#infix_operators_and_assignment
Maybe it's worth making an option? Not sure.

Commas in type signature currently has the same color as types, but commas elsewhere are the standard gray. Perhaps they should all be gray? Or they could all take on the color of their parentheses/brackets/braces level?

Hmm, I'm more open to making all commas grey than matching the parenthesis level from an implementation difficulty perspective, but both ideas seem worth considering aesthetically to me.

The in-comment blue-in-ticks should probably be dark blue to match the darker comment, otherwise the eye is drawn to it.

I think semantically code is the right face to use, and currently that's cyan to match the current Markdown tty rendering behaviour. This can be discussed a few different ways:

Terminal emulators will already use different brightness depending on their particular colour set
We can adjust the default colour of the code face
We can introduce a derived face with a different default foreground here, but I'd rather not if we can get away without doing so

@tecosaur - To be fair you did direct me to this PR for feedback :-) I can break out the defaults into a separate issue if you like.
The drive behind my suggestions, is that 1) a color change should signal something important, and too many color changes in a small space interferes with intelligibility; and 2) minimize the number of times the same color can mean different things. A default that follows these principles more closely will be a nicer user experience, however you want to achieve that.
Just a few other response points:

using a neutral color (gray/white) somewhere makes the colored special entities stand out more, and symbols/literals that can take arbitrary forms seem reasonable candidates for that
I could be wrong but it looks like the nothing is a dark purple while the literals (not symbols) are a light purple? That's what I was referring to there.
Using the color table Frames posted in Slack, the typical presentation is White text with Cyan code. It appears that in all terminals shown they're roughly similar brightness. Comments are using Bright Black I believe? So dropping Cyan to Blue, which has a similar drop in brightness across terminals, seems sensible. In your example screenshot a few posts up, I can barely see the comment and then "x" really pops out.

To be fair you did direct me to this PR for feedback :-) I can break out the defaults into a separate issue if you like.

All good, I just think it's helpful to separate the two in conversation. If nothing else, one takes a lot more effort than the other :stuck_out_tongue:
We can also continue this conversation after this PR is moved, I like to merge changes that improve a situation even if they're not perfect/end-state by themself, but that doesn't mean I think the work/conversation should stop once this PR is merged.
I'm in agreement with regards to wanting colour changes to signal semantic information/be actively helpful not just mimic a rainbow. The complication I think is that there are multiple reasonable ways of doing so. Figuring out a good balance here is an active WIP as far as I'm concerned
One of the reasons why more faces are used than there are ANSI colours, because I want to allow going beyond ANSI 4-bit colour. I think this affects "minimize the number of times the same color can mean different things" a bit.
I think we can "have our cake at eat it too" (somewhat) by using the inheritance pattern. E.g. the faces julia_string, julia_char, julia_number, julia_symbol, and julia_singleton could all inherit from julia_literal: this lets you customise the whole bunch at once, or target them individually :slightly_smiling_face:.

So dropping Cyan to Blue, which has a similar drop in brightness across terminals

I think you may have mixed up the bright and non-bright colours? Anyway, we'd also need to work out how to enact this change (we've got at least two options).

Let's merge this since it's an improvement, but keep on talking about how it can be made better :grinning:.
@BioTurboNick if I could convince you to make two issues, one on changes to defaults you think would be a good idea, and the other on changes in behavior that would be ideal: if not, no worries :slightly_smiling_face:.

Let's not let the perfect be the enemy of improvement :slightly_smiling_face:, I've moved some of the non-JuliaSyntax work that had collected here to #4, and I'd be keen to continue working on improving the highlighting across issues/future PRs.


Respect embedded vim window resizing on toggle

Thank you for this awesome plugin!
Here is an improvement suggestion
Problem
Whenever you resize your windows with vim embedded resize function, you might expect your toggling terminal windows to respect this setting after closing and opening them again
(personally I even have these remaps:
nnoremap <Up> :resize -2<CR>
nnoremap <Down> :resize +2<CR>).
Now, whenever Window.close is executed, it doesn't memoize window's width and height.
Next time Window.open is executed, it opens with its default settings
Solution
I tweaked it by modifying the Window.close function:
function Window:close(winid)
    if self:is_valid() then
        self.width = v.nvim_win_get_width(self.windid)
        self.height = v.nvim_win_get_height(self.winid)
        v.nvim_win_close(self.winid, false)
    end
end

My proposition is either to embed it as default behaviour or to make a setting for it

@susliko Now you can simply call require('nvim-terminal').setup() to setup everything. More about keymaps and customization are available in the README. The configuration still should work regardless the new updates.


A wave effect on buttons/icons

In every material design things I see, there is a "wave effect" on icons and buttons.
(here, an example of what I'm talking about: http://www.cssscript.com/demo/google-material-design-ripple-effects-with-wave-js/)
I think it could be a nice thing to add to this theme (specially for the red "+" button)

I already thought about it in the past but I wanted the theme to stay very simple and clean.
Then I may consider adding this as an optionnal setting. I'll think about it and update this ticket soon.

Thanks! But why an optional setting?

Because some users might find this heavy in terms of Javascript.
I did a first version that I tried to keep light and clean, you can test it via this commit: https://github.com/kalvn/Shaarli-Material/commit/0106a5cc7eb7248882e939e80a559db4556b9422

It really needs JS? It's not possible with CSS?

You cannot have something close enough to the original one provided by Google with just CSS, no.

Thanks!


Cannot read properties of null (reading 'classList')

TypeError: Cannot read properties of null (reading 'classList')
at wt.ac in src/vs/workbench/contrib/scm/browser/scmViewPane.ts:2399:15
at u.invoke in src/vs/base/common/event.ts:692:17
at s.deliver in src/vs/base/common/event.ts:899:22
at d.fire in src/vs/base/common/event.ts:860:11
at K.i in src/vs/platform/list/browser/listService.ts:752:10
at K.f in src/vs/platform/list/browser/listService.ts:704:8
at <anonymous> in src/vs/platform/list/browser/listService.ts:680:108
at u.invoke in src/vs/base/common/event.ts:692:17
at s.deliver in src/vs/base/common/event.ts:899:22
at d.fire in src/vs/base/common/event.ts:860:11
at <anonymous> in src/vs/base/common/event.ts:138:97
at <anonymous> in src/vs/base/common/event.ts:1188:15
at u.invoke in src/vs/base/common/event.ts:692:17
at s.deliver in src/vs/base/common/event.ts:899:22
at d.fire in src/vs/base/common/event.ts:860:11
at V.k in src/vs/base/browser/ui/tree/abstractTree.ts:1149:11
at V.set in src/vs/base/browser/ui/tree/abstractTree.ts:1139:8
at _.setSelection in src/vs/base/browser/ui/tree/abstractTree.ts:1742:10
at s in src/vs/workbench/browser/actions/listCommands.ts:451:8
at selectElement in src/vs/workbench/browser/actions/listCommands.ts:595:3
at fn in src/vs/platform/instantiation/common/instantiationService.ts:68:11
at b.k in src/vs/workbench/services/commands/common/commandService.ts:95:26
at b.executeCommand in src/vs/workbench/services/commands/common/commandService.ts:60:17
at Rs.G in src/vs/platform/keybinding/common/abstractKeybindingService.ts:304:12
at Rs.D in src/vs/platform/keybinding/common/abstractKeybindingService.ts:192:15
at <anonymous> in src/vs/workbench/services/keybinding/browser/keybindingService.ts:256:38

Go to Errors Site

Closing as duplicate of #159311.


Constant crash on start

I was adding code for the repositories so I could use this program. I got PSV tsv for games, dlc, themes.
Then I added pkg dec parameters -x {pkgFile} "{zRifKey}" --
Then CompPack URL: | https://gitlab.com/nopaystation_repos/nps_compati_packs/raw/master/entries.txt
CompPack Patch URL: | https://gitlab.com/nopaystation_repos/nps_compati_packs/raw/master/entries_patch.txt
and closed the window and reloaded. It now crashes constantly and i cant access the settings to change any information. Its stuck in a loop and I removing the DMG and app and restarting does nothing. Has this issue come up yet?

Where are you putting the pkg2zip parameters? Those aren't needed. Those parameters are changed based on the selected options in Preferences:

The only things that are needed by you are the URLs. You can try running the remove script from the Readme:
rm -r ~/Library/Application\ Support/NPS\ Browser/
rm -r ~/Library/Caches/JK3Y.NPS-Browser
defaults delete JK3Y.NPS-Browser

OMG Thank you! I couldn't find that file to delete and this worked perfect.
I love you, you magnificent beast!


Upgrade jason

Upgrade version of jason used to the latest release. Shouldn't be any breaking changes.

Yep, the changes look harmless.
BTW we should consider adding strings: :copy option to Jason.decode!(body) in PacketStream. In my experience this option drastically reduces memory usage and GC pressure when JSON parse results are passed between processes.

I think adding strings: :copy could be a good improvement, although we should do some benchmarking (if only informally).

Do you have any idea show to measure it?

Closing since this is fixed in #233. But opened #236 to investigate strings: :copy. And @wingyplus to measure it you could try :observer. But for any other discussion on this topic please use #236


fix(common): Proxy function toString does not contain Proxy.

Recent change (https://www.chromestatus.com/feature/5666372071718912) means Proxied functions
no longer throw TypeError.  Change the test to conform to the new reality.
Fixes #2942

What about all the old browsers that don't implement this change?

Older browsers should work fine, they just won't have fix-up serialization of proxy functions. I think that is a good trade off: rather than complex code for every browser we lose rare corner case support for old browsers.
(This issue now breaks the build since travis is runner chrome 66)


Fixed example

That's a great library, thanks!

Huh, maybe I used to have an auto type picking setValue()? Thanks for the fixes!


improve code lens provider performance

part of #11433
When looking at a large file with many code lenses, most of the code lens provider's is spent creating the code lens objects that are returned, and resulting gc calls. Even more is spent serializing those objects for the response, but that is outside the extension's scope.
This change focuses on speeding up the iteration through code lens range, reducing the getDocument and localize calls.
Parsing the file itself to divide it into cells isn't that large of an impact, so I didn't spend the time implementing a more complex incremental update.

It was probably not introduced in this PR but the check for text document uris seem wrong.

Codecov Report

Merging #11696 (c6cdeb9) into main (93c9c9e) will decrease coverage by 4%.
The diff coverage is 77%.

:exclamation: Current head c6cdeb9 differs from pull request most recent head d0071bc. Consider uploading reports for the commit d0071bc to get more accurate results

@@           Coverage Diff            @@
##            main   #11696     +/-   ##
========================================
- Coverage     47%      43%     -5%
========================================
  Files        483      483
  Lines      34447    34476     +29
  Branches    5601     5603      +2
========================================
- Hits       16532    14957   -1575
- Misses     16709    18161   +1452
- Partials    1206     1358    +152

Impacted Files
Coverage Δ

src/interactive-window/editor-integration/types.ts
100% <ø> (ø)

src/telemetry.ts
7% <0%> (-1%)
:arrow_down:

...tive-window/editor-integration/codelensprovider.ts
62% <50%> (-1%)
:arrow_down:

...teractive-window/editor-integration/codewatcher.ts
68% <75%> (+<1%)
:arrow_up:

...ctive-window/editor-integration/codeLensFactory.ts
65% <83%> (+4%)
:arrow_up:

src/kernels/raw/session/rawSocket.node.ts
4% <0%> (-64%)
:arrow_down:

src/kernels/execution/cellExecutionCreator.ts
5% <0%> (-60%)
:arrow_down:

src/kernels/installer/productPath.node.ts
33% <0%> (-58%)
:arrow_down:

src/kernels/execution/cellExecutionQueue.ts
6% <0%> (-57%)
:arrow_down:

src/kernels/raw/session/rawSession.node.ts
6% <0%> (-56%)
:arrow_down:

... and 110 more


Define metadata schema for variant and clinical information sources

[ ] #38

10/6 update
No update, we leave it on to make sure we link the Phenopackets model denoting the data model for the data is linked into the data model appropriately.
Nuria developed connection with phenopackets, used 'qualified relation' (or something like that in DCAT), based on suggestion by Mark W.

[ ] @NuriaQueralt will add the link to her work.
[ ] @mroos to create specific issue on the generalised issue (standard way to connect to model/shape denoting the data model/shape; tag @ericprud, @luizbonino @markwilkinson to agree on the EJP RD proposal for this (will go into final deliverable) and link it into this issue.


viewport texture transparency glitch if use panorama_sky from this viewport.

Godot version:
3.2 rc2.
3.1.2 work correctly.
OS/device including version:
win10 64
Issue description:
If i use viewport for panorama_sky in node WorldEnvinronment, and use this viewport for sprite texture, then with the change in the size of the sprite, its transparency changes. It should not be like that.
Steps to reproduce:
on video, https://youtu.be/Ff2rcxoZLZ8
you can comment/uncomment first string of script and change sprite size in editor.
Minimal reproduction project:
in attach. error.zip

Still valid in 3.2.4 beta4


requirements.txt: Bump IGitt version

Reviewers Checklist

[ ] Appropriate logging is done.
[ ] Appropriate error responses.
[ ] Handle every possible exception.
[ ] Make sure there is a docstring in the command functions. Hint: Lookout for
botcmd and re_botcmd decorators.
[ ] See that 100% coverage is there.
[ ] See to it that mocking is not done where it is not necessary.

ack a95c02e 6a256a1

@rultor merge

@rultor merge

@meetmangukiya OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@meetmangukiya Done! FYI, the full log is here (took me 2min)


Remove Yahoo Pipes dependancy

Need to either:

Parse iCal directly in client side javascript
Use a different 3rd party service to convert to JSON
Switch WatCamp.com to have server side processing such as Node

Since Yahoo pipes is dead maybe this issue is no longer relevant?

The JavaScript still refers to pipes. that's why the homepage no longer shows any events

Okay. I found some of those references. I guess I will strip them out?

Removed the dependancies myself. Put the full calendar embed on the homepage


QR image is not generating.

Even if i copy paste the URL it shows This site can’t be reached

I've been having same issue intermittently for past few days. Is there a workaround to bypass the QR if it fails?


[HxButton] Horizontal space (whitespace) between icon and text do not match for ButtonIconPlacement.Start|End

@hakenr instead of rendering a spacer before or after the icon, I have switched the button to flexbox and handle the gap with new CSS var --hx-button-gap that is used for spacing icons, dropdown caret and spinner. The --hx-button-icon-text-spacer-width is now obsolete.


FEATURE Request - New stats and fields

Hi, I am loving this application and thank you for building this as the existing ones did not provide information at this level.

I would love to see if how many miles between specific types of service(tags). For example, average of 5,100 miles between Oil changes. Ideally based on tags from the service records. I am tagging my service tags with component names like Front Brake Pads or Front Brake Rotors and etc.

New Vehicle fields:

VIN Number
Trim
Engine
Paint Code
Radio Code
Purchase Date
Purchase Mileage
Purchase Dealership
Purchase Price

As of 1.2.4 you can now add extra fields at the vehicle level. Still looking into item 1 tho.

@varunpan released in 1.2.5
Watch: https://youtu.be/I2KlO5PVHCc?si=wGxBt72q6UNFLxJy&t=267

In 1.2.5, if you hold down CTRL and select the records, you can actually select multiple records not just consecutive ones. You can also use the Search feature to filter the Oil Change records

Hmm I haven't got a Mac to try, does shift+click do anything on Macs? I might have to look into adding that as an alternative for next release, for now I think you can use the search feature along with tagging records.


refactor(katana): change stored compiled class

Both blockifier and starknet_in_rust use their own proprietary contract class types. So need to have a type where the types from those two crates can be derived from.

Current dependencies on/for this PR:

dev/katana

PR #1559   👈

PR #1560

PR #1561

PR #1562

This stack of pull requests is managed by Graphite.

Merge activity

Feb 29, 1:56 AM EST: @kariy started a stack merge that includes this pull request via Graphite.


Prerequisits not avaialbe for 365 V9 installation

When installing the new on-premise version 9.0 of Dynamics, a number of required components are prompted for.  Selecting to proceed with Download and install results in nothing being available.  The install asks for SQL Native Client 11.4.7001 as a minimum, SQL System Clr Types 13.0.1601 and error reporting 12.0.6015.5000.  It tries to download these but fails and I cannot find these components for download.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: aeaa6972-820b-f3a1-3bc2-291032c31697
Version Independent ID: 7fd96ef1-257d-4cbc-1803-f729fdc6f612
Content: Install or upgrade Microsoft Dynamics 365 Server
Content Source: ce/on-premises/install-or-upgrade-microsoft-dynamics-365-server.md
Product: crm-2016
GitHub Login: @Mattp123
Microsoft Alias: matp

as far as i know 9.0 is for  MS Server 2k16 only... and if that not works i got some links for ya.
"Operating system 	Notes
Microsoft Windows Server 2016 Datacenter or Standard 	These requirements are for the database and the Service Fabric cluster that hosts AOS.
Only en-US OS installations are supported."
and for your errors take this: https://www.microsoft.com/en-us/download/details.aspx?id=52676 & https://blogs.msdn.microsoft.com/crminthefield/2013/11/21/how-to-install-microsoft-dynamics-crm-2013-without-an-internet-connection/


feat(compaction): add vnode watermark picker

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
close #17157

Add a new picker that picks trivial reclaim compaction task. For simplicity, this picker only takes bottommost level into consideration.
Extract SkipWatermarkState::from_safe_epoch_watermarks and HummockVersion::safe_epoch_table_watermarks into pure functions for easier reuse.
Add a CompactionSelectorContext to convey parameters to compaction selectors.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

One issue is compaction tasks of dynamic type has the highest priority, potentially starving space reclaim tasks.

One issue is compaction tasks of dynamic type has the highest priority, potentially starving space reclaim tasks.

The assumptions are:

dynamic task should be done ASAP because it will cause write stall
dynamic task will also reclaim tombstones/space if it can

2 is not 100% valid because dynamic task will not take reclaim releated statistics like tombstone ratio into consideration. Also, for trivial reclaim task, which uses very few resource, it can be done relatively fast and won't block dynamic tasks.
However, this is a separate issue pre-exists prior to this PR so we don't need to block this PR because of that.

/test

Failed: 1
Passed:0
FailedExecutions:
https://buildkite.com/risingwave-test/compaction-test/builds/176
PassedExecutions:

Failed: 1
Passed:0
FailedExecutions:
https://buildkite.com/risingwave-test/compaction-test/builds/176
PassedExecutions:

/test

Failed: 0
Passed:2
FailedExecutions:
PassedExecutions:
https://buildkite.com/risingwave-test/compaction-test/builds/177
https://buildkite.com/risingwave-test/compaction-test/builds/177

Do we have a integration test (like the one in compaction test pipeline maybe?) to verify the effectiveness of the new picker?

I'm still considering how to add the corresponding tests.


Object.Paths not produced error with optional sub props.

Hi,
I would like to report a bug.
🐞 Bug Report
Describe the bug
Object.Paths does not produce an error if optional properties exist in sub properties.
Reproduce the bug
import { Object } from 'ts-toolbelt'

export interface LineItem {
  modifications: Record<string, {rate?: number; amount?: number}>
}

export interface Mandatory {
  modifications: Record<string, {rate: number; amount: number}>
}

export function useVModel<PROPS extends object, PATH extends Object.Paths<PROPS>>(
  props: PROPS,
  path: PATH,
): any {}

export function useLineItem(
  lineItem: LineItem,
  mandatory: Mandatory,
): any {
  useVModel(lineItem, ['XXXXXXX']) // First Call
  useVModel(mandatory, ['XXXXXXX']) // Second Call
}

Expected behavior
Both calls should produce errors.
What happens
The first call does not produce an error, whereas the second call produces an error.
Screenshots

Additional context
"ts-toolbelt": 9.6.0
"typescript": 4.2.3
"node": 15.8.0

Thanks for reporting this

Any updates on this issue?


fix(shared): get ipv4 interfaces should be uniq & set @types/fs-extra…

… as devDeps
Summary
Sometimes, we will get many ipv4 address.But some are same,so address should be uniq.

Related Issue

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM!


Mosek 9.0

I have installed Mosek 9.0. But Mosek.jl seems to be 8.0. I checked some of the older issues that, to my understanding, say that removing and readding the package should force Mosek.jl to download the latest version, but it does not seem to be doing so. Is there a way I can manually point Mosek.jl to the 9.0 I have installed. I do not have 8.0 installed manually.
Any help would be greatly appreciated!

IIUC (@ulfworsoe correct me if I am wrong), the current release of Mosek.jl which is on the b0.9 branch (https://github.com/JuliaOpt/Mosek.jl/tree/b0.9) is for Mosek v8.0:
https://github.com/JuliaOpt/Mosek.jl/blob/5996662b755779f0c5bf20b4e61eb94af7728f95/deps/build.jl#L4-L5
The development for Mosek v9.0 is done on the master branch:
https://github.com/JuliaOpt/Mosek.jl/blob/efebef81c8c81812a686668618bce386c25f8bd8/deps/build.jl#L4-L5
but there has been no release yet. You can try it with import Pkg; Pkg.add(Pkg.PackageSpec(name="Mosek", rev="master")) or just ] add Mosek#master in the REPL.

I have made a release for MOSEK 9.0. It should be available when it has been approved, meaning that installing or upgrading the MOSEK package should give you a MOSEK 9.0. Note that licenses for 8.1 will probably not work with 9.0.
MOSEK has been out in a beta version, but we only just released officially recently, and we are in the process of making 9.0 the default version.

may I ask how you install Mosek9.0?
When I input Pkg.add(Pkg.PackageSpec(;name="Mosek", version="9.0")) I received the message that I was inputting wrong version in Julia 1.0.5

I haven’t used this in a while, but after downloading their tarbells, I unzipped it to some directory and added that directory to my path.
Hope this helps.

On Aug 6, 2021, at 4:45 PM, CynthiaChenyx @.***> wrote:
may I ask how you install Mosek9.0?
When I input Pkg.add(Pkg.PackageSpec(;name="Mosek", version="9.0")) I received the message that I was inputting wrong version in Julia 1.0.5
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MOSEK/Mosek.jl/issues/177#issuecomment-894106881, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKHKMC3AW5PSEQOEZNPJRDT3OOLLANCNFSM4HMMNW7A.


Initial commit of streaming Kendall's Tau algorithm.

Description
Brief Description of the PR:
Introduces a streaming Kendall's Tau metric implementation.
Fixes # (issue)
Type of change

[ ] Bug fix
[ ] New Tutorial
[ ] Updated or additional documentation
[ ] Additional Testing
[ ] New Activation and the changes conform to the activation contribution guidelines
[ ] New Callback and the changes conform to the callback contribution guidelines
[ ] New Image addition and the changes conform to the image op contribution guidelines
[ ] New Layer and the changes conform to the layer contribution guidelines
[ ] New Loss and the changes conform to the loss contribution guidelines
[ x ] New Metric and the changes conform to the metric contribution guidelines
[ ] New Optimizer and the changes conform to the optimizer contribution guidelines
[ ] New RNN Cell and the changes conform to the rnn contribution guidelines
[ ] New Seq2seq addition and the changes conform to the seq2seq contribution guidelines
[ ] New Text addition and the changes conform to the text op contribution guidelines

Checklist:

[ ] I've properly formatted my code according to the guidelines

[x] By running Black + Flake8
[ ] By running pre-commit hooks

[ ] This PR addresses an already submitted issue for TensorFlow Addons
[ ] I have made corresponding changes to the documentation
[ x ] I have added tests that prove my fix is effective or that my feature works
[ ] This PR contains modifications to C++ custom-ops

How Has This Been Tested?
If you're adding a bugfix or new feature please describe the tests that you ran to verify your changes:
*

Just a final edit, can you add yourself in https://github.com/tensorflow/addons/blob/master/.github/CODEOWNERS for this?


allow optional CN in reissue and clone

Extension of https://github.com/Netflix/lemur/pull/4732

coverage: 75.534% (+0.001%) from 75.533%
when pulling ce6b96e96c9933a2991fd988905312ff95a1f7da on charhate:async-optional-cn
into efd2255d19582d82e9dbb021aa93a0212b9ddd22 on Netflix:main.


Add useProxies to registryMirror allowing to mirror more than docker registries

Description
Add a new field in registryMirror, allowing to use proxies list to decide whether to use dragonfly.
By doing this, it is now possible to cache more than only blobs/sha256 urls, allowing to use dragonfly2 for other usage thatn docker registries, like yum repositories.
Also fix the whiteList test which is tested on direct request, although host is empty and canno tbe tested.
Please update the documentation in Chinese, I just can't do it.
Related Issue
#959
Motivation and Context
This PR now allows to use dragonfly to mirror yum repositories, at least.
Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Please sign off the commits, the guide is here: https://github.com/dragonflyoss/Dragonfly2/pull/963/checks?check_run_id=4653192590

Codecov Report

Merging #963 (4a71a51) into main (c6b7ab9) will increase coverage by 0.18%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main     #963      +/-   ##
==========================================
+ Coverage   42.33%   42.51%   +0.18%
==========================================
  Files         116      116
  Lines        8783     8789       +6
==========================================
+ Hits         3718     3737      +19
+ Misses       4597     4586      -11
+ Partials      468      466       -2

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
42.51% <75.00%> (+0.18%)
:arrow_up:

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

Impacted Files
Coverage Δ

client/config/peerhost.go
35.29% <ø> (ø)

client/daemon/proxy/proxy.go
8.81% <75.00%> (+1.54%)
:arrow_up:

client/daemon/peer/peertask_base.go
46.53% <0.00%> (-0.58%)
:arrow_down:

client/daemon/peer/piece_manager.go
63.46% <0.00%> (+0.64%)
:arrow_up:

client/daemon/peer/peertask_stream_callback.go
64.07% <0.00%> (+1.94%)
:arrow_up:

client/daemon/peer/peertask_stream.go
57.58% <0.00%> (+4.02%)
:arrow_up:

OK I completely screwed the signoff thing...
Doing the rebase HEAD --signoff applied a double signoff to commits from other people.
I'll create a new PR for this...


Upgrade to capacitor 4

Closing this PR, expecting that it's superseded by https://github.com/bcgov/nr-bcws-wfnews/pull/714


a little bug

When I have seven icon, click on the left three ICONS no problem, but when click on the three ICONS on the right, there will be a shake!

I have already solved, there are two places need to change the 360 to 360.0 f!

@FANK-CN Nice catch! Just pushed a fix. Thanks for helping me solve this problem.


Support new reference syntax in scripts (.NET 5)

If the new reference syntax for NuGet packages in F# scripts with .NET 5 is used, the import is not recognized by the VS Code/Ionide.
Example: script.fsx
#r "nuget: SharpYaml"
open SharpYaml.Serialization

Gives the error message:
The namespace or module 'SharpYaml' is not defined.F# Compiler(39)
The namespace or module 'SharpYaml' is not defined.(39: typecheck)

The script itself is executable with dotnet fsi --langversion:preview .\script.fsx. The reference is just not recognized by the IDE.

This will be supported when FCS 35 releases along with the FSharp.DependencyManager.Nuget package. I'll try to do that this weekend. There will be a long tail of other dependencies, like fsharplint and fantomas, that also need to update, so this could take a while.

@baronfel anything I could help with?

This should be supported now

It's not released due to https://github.com/fsharp/FsAutoComplete/issues/593 and https://github.com/fsharp/FsAutoComplete/issues/594

Thanks for the update @baronfel & @Krzysztof-Cieslak. These bugs are really a blocker :(

This should be enabled in 4.10... but we'll probably need one more fix to support .Net 5 previews correctly.

I've tried this in 4.11.1 and it's still not working, even if I have "FSharp.fsiExtraParameters": [ "--langversion:preview" ] in settings.json

Re-instaling the .net core sdk 5 preview fixed it, so never mind

Unfortunately doesn't work for me. I've Ionide 4.11.1 installed and set the "FSharp.fsiExtraParameters": [ "--langversion:preview" ] in settings.json. I've reinstalled .NET Core Preview 5.4 but I'm still getting
Package manager key 'nuget' was not registered in [c:\Users\x\.vscode\extensions\georgewfraser.fsharp-language-server-
0.1.27\src\FSharpLanguageServer\bin\Release\netcoreapp3.0\win10-x64\publish; c:\Users\x\.vscode\extensions\georgewfraser.fsharp-language-server-
0.1.27\src\FSharpLanguageServer\bin\Release\netcoreapp3.0\win10-x64\publish\], []. Currently registered:

F# Snipped
#r "nuget: FSharpPlus"
open FSharpPlus

The script runs fine when executed from command line with the preview option.
Am I doing anything wrong or is there some more information you need to look into that?

@secana your error message says that you're using fsharp-language-server here, not ionide. That is a completely different extension, and I'm not sure it has been updated to support #r nuget.

@baronfel you are right! Uninstalling the F# Language Server extension solved the issue. Thx for pointing that out. Kind of obvious now...

what can be wrong if I get no problems with #r "nuget: FSharpPlus"
but red understriked open FSharpPlus?

It's important to understand that right now #r "nuget" is slow. The F# team has it on their work plan for the next three weeks to look at this in greater detail.
Aside from that detail, it's also important to understand that you'll never see red squigglies on the #r declaration itself if it is valid in structure. Instead you'll see red squigglies on the open statements if the restore hasn't occurred yet, or the nuget provider is still resolving dependencies, etc.  The best I can suggest is to wait for an additional time longer, or check the output logs for Ionide for more details. There should also be upcoming work from the F# team around logging/status of the nuget provider, so we can give you more details in these scenarios.  The feature is in preview, however, and there will be rough edges like these.


Enhancement: improve logging, move it from log.warnings to prints with ability to suppress

 PyCaret client modifications


Generalize AnnTip

Previously AnnTip looked like
 data AnnTip blk = AnnTip {
       annTipSlotNo  :: !SlotNo
     , annTipHash    :: !(HeaderHash blk)
     , annTipBlockNo :: !BlockNo
     , annTipInfo    :: !(TipInfo blk)
     }

That double use of blk is problematic. Consider what happens when we instantiate this to HardForkBlock: the hash of a hard fork block is a hash from one of the eras (Byron hash, Shelley hash, ..), and similarly the TipInfo of a HardForkBlock is the tip info from a particular era. But if we instantiate this twice, independently, then we lose the information that these two must be related; it doesns't make sense to have a block with a Byron header but with Shelley info.
Therefore in this PR we delete annTipHash altogether, and instead insist that we must be able to derive the HeaderHash from the TipInfo.
The first 4 commits in this PR are all designed specifically to ensure that introducing this change does not break backwards compatibility. The encoders/decoders for AnnTip still encode the information in precisely the same order; only the in-memory representation is now different.

bors merge


Process Explorer: NVDA does not announce CPU% and Memory(MB)

Environment Details:
VSCode Version : 1.24.1
OS Version : Win10
Additional Details:
ScreenReader Version: NVDA2018.2
Repro Steps:

Launch VS Code while NVDA is ON.
Go to Help--> Open Process Explorer

Actual:
NVDA does not announce any information about the data changing dynamically in CPU% and Memory(MB).
Expected:
NVDA should announce some information about the data which is changing dynamically in Column1(CPU%) and Column2(Memory)
Recommendations:
Refer below link which is repository of bug fixes code snippets:
https://microsoft.sharepoint.com/teams/msenable/mas/pages/browse-fixes.aspx
User Impact:
User will not be able to know about the data which are changing.
Attachment for Reference:
A11y VSCode Process Explorer NVDA does not read content changing.pptx
Does this issue occur when all extensions are disabled?: Yes

@RMacfarlane is it ok if we look into this in September? It seems low hanging and we need this to achieve a better accessibility grade.

This is actually more difficult to fix than I thought it would be - the whole table's HTML gets updated every second, only the top level element is in the HTML that gets initially loaded. Putting aria-live: "polite" on that element causes NVDA to start reading the entire table when values have changed, instead of just the specific entry. And putting aria-live on any specific cell doesn't work since the cell needs to be in the document when it first gets loaded for NVDA to listen for changes to it.
I opted for adding aria-live: "polite" on the top level so that at least something is read on update. Right now I can't think of a way to scope it down any further

It now reads a text every second that is too long to be read/understood within a single second. I'm not a screen reader user myself, so I can't tell for sure, but does that really fix it?

Agree with @chrmarti 's observation. While something is now read, I think the bug itself should be re-opened and fixed later.

Even though I agree that the solution is not optimal. There is no better way to fix this via aria spec.
Optimally we would read out more rarely. However none of the users complained on this and the original issue is fixed. Thus closing


fixing the stopwatch button

@avinash201199 I want to fix the stopwatch Button on the home page because its not linked/redirected to the same page and just showing # in the url.....Can you plzz tell should I remove the click option from that....or I must redirect it to same page? And plzzz assign this task to me

That's the heading so you can remove the click option


fix: change support url

update support url
Issue

Link:
Summary:

How

Screenshots

References

Checklist

[ ] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

Hey @shawaj, you just changed the visible link, but not the actual URL!

@Ryan-Goldstein lol - this is why you shouldnt code at 3am :-P

Fixed now thanks @Ryan-Goldstein

The magic of open source - the entire world can look over your shoulder and point out your mistakes. 😄

The magic of open source - the entire world can look over your shoulder and point out your mistakes. 😄

Love it :-P


Update package names

I hope this works also for Ubuntu and other debian
based distros. It's at least needed on raspian.
Fixing problems like this:
building 'gattlib' extension
arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DVERSION="5.25" -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -Isrc/bluez -I/usr/include/python3.4m -c src/gattservices.cpp -o build/temp.linux-armv7l-3.4/src/gattservices.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
In file included from /usr/include/boost/python/detail/prefix.hpp:13:0,
                 from /usr/include/boost/python/list.hpp:8,
                 from src/gattlib.h:11,
                 from src/gattservices.cpp:12:
/usr/include/boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
 # include <pyconfig.h>
                       ^
compilation terminated.
error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1

Also setuptools might not be installed by default.

Thanks!


Append Test::More into strict.t

Because, most of tap scripts on Perl5 are detected as Perl6.

Thanks for the pull request!

Yes, code in above detected as Perl5 with this change. BTW, the word More is counted as heuristic level 2 for Perl6. But it's not code. it's in comments. So it's not fair.
https://github.com/github/linguist/blob/master/samples/Perl6/test.p6#L90-L93

Yes, code in above detected as Perl5 with this change.

In that case, could you explain a little more whats happening here? I don't know what is a tap script in Perl. Also, is Test::More specific to one of the versions or is it common to both?

BTW, the word More is counted as heuristic level 2 for Perl6. But it's not code. it's in comments. So it's not fair.

So the comment starts here but I can't see where it's supposed to end...?

In that case, could you explain a little more whats happening here? I don't know what is a tap script in Perl. Also, is Test::More specific to one of the versions or is it common to both?

Perl6 doesn't have Test::More. But the script using Test::More is handled as Perl6. Because the word More is counted as 2 in Perl6 in the code as I said in above. My change add More word into Per5 script is fixing this problem.

So the comment starts here but I can't see where it's supposed to end...?

next /^=/. but not. so it's EOF.

Thanks for the explanation :+1:

next /^=/. but not. so it's EOF.

Okay, then, could you also remove those lines in your pull request? I'm not a big fan of changing samples but it looks like we don't have a choice here since the tokenizer doesn't handle Pod comments :/

Best way to fix this issue is handling string literals well, parse pod correctly, and ignoring all of non-syntax literals. If you think it's harder to do, I'll remove this as your said.

Best way to fix this issue is handling string literals well, parse pod correctly, and ignoring all of non-syntax literals. If you think it's harder to do, I'll remove this as your said.

Take a look at tokenizer.rb, you'll see that it's not that simple. We would have to parse all languages and not only Perl ;)
There was a project for Google Summer of Code about this (using the Sublime Text/TextMate grammars we know to parse files) but no student was selected to work on it.
For the time being, I think you should just remove this section ;)

okay, will do. then, I should revert adding Test::More?

then, I should revert adding Test::More?

As you wish.

I will remains Test::More because Test::More is used in Perl5 but not in Perl6. The word More should be prevailed to Perl5.

@arfon This looks ready to be merged to me :-)

:+1: thanks @mattn & @pchaigno. This should be live in the next release of Linguist (next week).


Fix: Not here page shows up when opening tax with special characters

Details

This PR fixes the issue that not here page shows up when clicking on tax rate with / symbol.
Fixed Issues

$ https://github.com/Expensify/App/issues/39614
PROPOSAL: https://github.com/Expensify/App/issues/39614#issuecomment-2037457811
Tests

Create several taxes with special characters in name (- _ . ! ~ * ' ( ) ; / ? : @ & = + $ , #)
Open each of them, navigate to its name and value page
Verify that those page opens and special characters in tax name in URL is encoded correctly

[x] Verify that no errors appear in the JS console

Offline tests

NA
QA Steps

Create several taxes with special characters in name (- _ . ! ~ * ' ( ) ; / ? : @ & = + $ , #)
Open each of them, navigate to its name and value page
Verify that those page opens

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/153004152/bd14e284-6926-4f82-8d6a-59242324df24

Android: mWeb Chrome

https://github.com/Expensify/App/assets/153004152/2e1406e9-10f6-4fc2-82eb-dd005faf1324

iOS: Native

https://github.com/Expensify/App/assets/153004152/afa57399-07e9-4c65-ab47-1e9d379c6747

iOS: mWeb Safari

https://github.com/Expensify/App/assets/153004152/f78a7cb3-dd7b-49ab-879b-9e4a05b44f0b

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/153004152/37d55e90-eb5d-4750-b3e7-4b05d0ae6400

MacOS: Desktop

https://github.com/Expensify/App/assets/153004152/70d5a44b-5389-4373-bec0-c2b65840e848

Please update the steps to:

Go to Workspaces > any paid workspace > Taxes
Press Add rate and add a rate with name containing special characters e.g. Tax/+?Tax
Click on the added rate
Verify you are able to change the name and value

Reviewer Checklist

[X] I have verified the author checklist is complete (all boxes are checked off).
[X] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[X] I verified the steps for local testing are in the Tests section
[X] I verified the steps for Staging and/or Production testing are in the QA steps section
[X] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I checked that screenshots or videos are included for tests on all platforms
[X] I included screenshots or videos for tests on all platforms
[X] I verified tests pass on all platforms & I tested again on:

[X] Android: Native
[X] Android: mWeb Chrome
[X] iOS: Native
[X] iOS: mWeb Safari
[X] MacOS: Chrome / Safari
[X] MacOS: Desktop

[X] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[X] I verified proper code patterns were followed (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I verified that this PR follows the guidelines as stated in the Review Guidelines
[X] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[X] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[X] I verified that all the inputs inside a form are aligned with each other.
[X] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

🚀 Deployed to staging by https://github.com/stitesExpensify in version: 1.4.62-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/stitesExpensify in version: 1.4.62-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.62-17 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Values from environments are not merged into chart's Values

Helmfile version: v0.144.0
With the following example:
chart1/templates/file.yaml
# --> {{ .Values.test }}

helmfile.yaml
environments:
  default:
    values:
      - test: true

releases:
  - name: one
    chart: chart1

helmfile template renders the following:
Building dependency release=one, chart=chart1
Templating release=one, chart=chart1
---
# Source: chart1/templates/file.yaml
# -->

Shouldn't it take the values from the default environment?

Hey. It's working as intended. Helmfile environment values and release values are completely different things!

Hi @mumoshu, thanks for your answer. But as far as I understand from this section of the README, it should work as the example I gave.
# Everything from the values.yaml is available via `{{ .Values.KEY }}`.
# Suppose `{"foo": {"bar": 1}}` contained in the values.yaml below,
# `{{ .Values.foo.bar }}` is evaluated to `1`.

@daper No. It says it's literally available via {{ .Values.KEY }} within the helmfile.yaml and release values templates. It's never meant to be "merged" into release values as YAML.


Forward X-Request-ID to tenant service

Fixes lack of log coordination between tenant service and core.
client.ContextRequestID != middleware.ContextRequestID as they are stored
under different local keys.

[test]


Feature/update check

Check for updates using the latest tag from github and comparing it using semver

Merged this to develop now, made a few changes letting you ignore specific versions and added the ability to manually check for updates. Looks like it works really well, thanks!


version changed to 2020.08.001

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@suvmanda thanks for this PR 👍
Could you please sign the CLA:
https://github.com/devonfw-forge/devon-guide/wiki/cookbook-cla


Add files via upload

@lucaross06 First stage of verification passed, official domain is liceopaleocapa.edu.it as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@lucaross06 Hi!
Please provide us with a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

You can provide us with any of the following:

A copy of instruction (a hard-copy or electronic one) given to you by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that students use this email domain
A reference to a recognized journal where an article was published by someone from the school, with explicit affiliation to the school, and e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be verified independently.

Thank you!

@lucaross06 Thank you for your patience while waiting for a review and processing your request. Pull request merged.