runtime: automatically bump RLIMIT_NOFILE on Unix

I just read http://0pointer.net/blog/file-descriptor-limits.html which in a nutshell says:

don't use select
systemd sets the RLIMIT_NOFILE soft limit to 1024 for compatibility reasons, to not break select users
systemd sets the RLIMIT_NOFILE hard limit 512K, for programs that want more (without escalation), but by raising their soft limit past 1024, they're implicitly acknowledging that select won't work.

I realize that since Go doesn't use select, the Go runtime could automatically do this fd soft limit bumping on Linux.
We do have a Select wrapper at https://pkg.go.dev/golang.org/x/sys/unix#Select, though, so perhaps we could do the same thing we did for #42347 in 18510ae88ffcb9c4a914805fde3e613539f9b6dc (https://go-review.googlesource.com/c/go/+/299671) and do the bumping conditionally based on whether the unix.Select func is in the binary. Or cgo too, I suppose.
I suspect many users are unaware of this 512K hard limit that's free to bump up to. I certainly was unaware. (I normally have to go in and manual tweak my systemd limits instead, usually in response to problems once I hit the limit...)  I think fixing it automatically would help more users than it'd hurt. (I actually can't think how it'd hurt anybody?)
I don't think we need it as a backpressure mechanism. As the blog post mentions, memory limits are already that mechanism.
/cc @ianlancetaylor @aclements @rsc @randall77

The limitation on select is not a kernel limitation.  It's a limitation on the implementation of fd_set in glibc.  And we've inherited that limitation in x/sys/unix.FdSet, but perhaps we could fix that.  If we did, then we could raise the soft limit to the hard limit unconditionally.
I note that on my Debian system the soft and hard limits are both 131072.  On my CentOS 6 system the soft limit is 1024 and the hard limit is 4096.  On my recent Fedora system the soft limit is 1024 and the hard limit is 524288.

Yeah, I saw our FdSet was struct { Bits [16]int64 }. Make it opaque with a [16]int64 used by default and a spill-over lazily-allocated bitmap when (*FDSet).Set(fd int) is called with a "big" fd? Doable, but I wonder if it's worth the effort. Does anybody actually use unix.Select?
We'd still need a conditional mechanism regardless for cgo I assume, as we wouldn't know whether C code was using select as easily?
FWIW, on my various Debian (buster) & Ubuntu (focal LTS, hirsute) machines here, I see 1024 & 1048576.

Does anybody actually use unix.Select?

I'm happy to get rid of that and replace it with poll. (Want to send a patch?)
This proposal sounds like a good idea, with the caveat that we probably shouldn't do it in initialization for -buildmode=shared.

What happens today, even in programs that do nothing but file I/O (no select etc), is that if you open too many files you get errors. Auto-bumping would let those programs run longer.
If Go did it at startup, it would be inherited by non-Go programs that we fork+exec. That is a potential incompatibility, but probably not a large one. Technically, I suppose we could undo it in the subprocess between fork and exec.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

To summarize the limitating use cases where we should not be raising the soft limit.

select implementation from glibc (or other libc like musl too?) is used
cgo is used because dynamic linking can load anything with dlopen and also can cause exec calls in places we don't know.
select implementation from our own syscalls or unix package is used, unless that one is changed as suggested above.
NSS (user/group lookup and DNS lookup) is used from glibc.
and we need to reset, if we call the exec family of syscalls

One problem with restoring the limit in exec is we won't know if the limit was intentionally changed by the program in the interim. What about programs that explicitly raise the limit and then exec today? We would be dropping it back down.
It seems like if we are going to raise the limit, we should just do that, not try to put it back.
I just ran into this problem with gofmt on my Mac, where the limit defaults to 256 (and gofmt was editing many files in parallel). I'd love for Go to raise the limit there too.
How much does it really matter if we raise the limit for a subprocess?
People can always set the hard limit if they want Go not to try to bump the soft limit up.

It's pretty awful that the limit is breaking completely reasonable Go programs like gofmt -w.
It seems very wrong for gofmt to have to put a bump in.
It seems like we should bump the limit at startup - Go doesn't use select.
It's very hard to see any programs benefiting from this limit in practice anymore.
I understand that systemd can't make such a global decision, but I think Go can.

I think that seems quite reasonable.
We can even document this in unix.Select/syscall.Select and mark them as deprecated so that editors bring attention to them and maybe add something to go vet too. It seems always possible to move to poll or similar.

Not sure anyone is using syscall.Select for fd's anyway.
Every time I've used it in the past decade it has been to get a sub-second-resolution sleeping API (selecting on no fds).

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

Should the title be updated to mention Unix or something instead of Linux?
Personally, I constantly run into that limitation on macOS; would like to see that resolved.

The considerations may be different on different Unix systems.  On Linux the details are somewhat specific to systemd.
It may well be appropriate to do this on macOS also, but I don't know what the tradeoffs are there.  Why does macOS have a default low limit?

From what I was able to find, that default goes back to the very first OS X release and probably even back to BSD. The constant is there.
Of course, not doing that on macOS is not a deal-breaker but an annoyance.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The test for this change is failing on at least three builders — looks like we may need to plumb in OPEN_MAX for the case where getrlimit reports RLIM_INFINITY instead of the true max.

So I suppose one option might be to try the setrlimit call with the limit as given by getrlimit, and if that fails fall back to increasing to some reasonable-but-arbitrary constant (ideally equal to OPEN_MAX)..?

Some more info at #40564.

I put in a call to sysctl kern.maxfilesperproc. Hopefully that exists on the older macOS. And I skipped the OpenBSD failure entirely. (It is not a first-class port.)

How much does it really matter if we raise the limit for a subprocess?
People can always set the hard limit if they want Go not to try to bump the soft limit up.

I understand that systemd can't make such a global decision, but I think Go can.

FWIW, containerd previously could use systemd to configure limits with LimitNOFILE=1024:524288 in a service file. All containers and the processes they run would inherit those limits, and could optionally raise their own soft limits.
Since Go 1.19, providing an explicit soft limit this way does not work anymore. It'll get raised implicitly to the hard limit assigned, I'm not sure if containerd was aware of this as their default config shipped is LimitNOFILE=infinity.
High RLIMIT_NOFILE (especially the soft limit) has been a source of confusion and difficult to troubleshoot problems from users when software (particularly daemons) was not designed to operate on a range spanning over a billion file descriptors (each with a close() syscall and the majority not open) stalling with heavy CPU load, or allocating ridiculous amounts of memory (thousands more).

Presently, if one relies on the default limits systemd assigns (1024:524288), even on Debian based systems where the system-wide hard limit per-process (fs.nr_open) is 1048576 (2^20) instead of 2^30, the implicit behaviour could not be opt-out by the user, unless they raise the hard limit to infinity.
Was it intentional to require assigning a hard limit as high as 2^30 to a process, just so a lower soft limit could be applied?
I understand this is technically niche (beyond the popularity of the software itself), but due to each process belonging to a container, and each container belonging to the parent containerd, the hard limit for containerd needs to be sufficiently high, but a soft limit at that same limit is worse to troubleshoot abnormal behaviour vs an error message of too many files being open.

I've reported the regression to containerd, and assume it's something they should attempt to resolve on their end? (assuming they can opt-out internally, or know the original soft-limit)

@polarathene I don't see the connection between what you describe and the Go runtime.  Is containerd a Go program?  If so, I agree that they should be aware of this change and should configure their limits accordingly.

I don't see the connection between what you describe and the Go runtime.

containerd creates containers, which run various processes, they all are run from the same containerd process parent, thus inherit the limit.
Setting a soft limit on the OS for containerd to respect worked well until Go 1.19 released (and a new release of containerd arrived). Now the soft limit is ignored unless the hard limit is infinity (typically 2^30).
One must now choose either a soft limit with an impractical hard limit, or a practical hard limit without control of the soft limit.
This Go 1.19 change is the source of that regression slipping through (I don't think many Go programs had tests in place to ensure limits set externally were respected, since that was reliable / consistent when set explicitly via ulimit or similar). This was not something containerd had to decide / manage internally.

Is containerd a Go program?

Yes, it is heavily used for for containers with Docker and Kubernetes:

https://containerd.io/
https://github.com/containerd/containerd

If so, I agree that they should be aware of this change and should configure their limits accordingly.

I am not a Go developer, and it's not clear to me if the feature is opt-out beyond raising the hard limit to infinity / 2^30.
I have raised a bug report to containerd as mentioned earlier, but I'm not sure if the changes introduced here for Go 1.19 still allow for running with the original inherited limits like before Go 1.19?
Can containerd still know the original soft limit and restore that value? Or is it lost by the time the limit is raised implicitly?

containerd relied on external limits being set for this (while shipping a default in the past of 1048576, presently infinity) as the relevant limits depend on environment (eg: local dev vs production at scale).

The limits can make some builds in containers take 10 hours instead of 15 minutes.
In my own experience a popular Python project that would start in 1 second would instead take 70 minutes. These can generally be avoided by a soft limit, and this will still work with Go 1.19 if using infinity as the hard limit.
Some software has been known to behave similar to Go 1.19 and implicitly raise soft to high limit, but also not intended to run with a hard limit as large as a billion, which at that size allocates excessive amounts of memory causing failure from OOM_).

There are workarounds available at the container level, but these were not needed previously (configuring RLIMIT_NOFILE in a systemd unit that is applied before running containerd).
I just wanted to chime in and raise awareness of a problem case from this change. As a user, it was a surprise that my explicit soft limit was not respected (because I did not want to have a hard limit of infinity).

Original response
Well they do configure limits via configs for each init system like systemd, that would set a soft + hard limit (sometimes a single value for both). Presently it's infinity which is not appropriate for the soft limit, and manually setting the soft limit back to 1024 worked fine until a release was built with Go 1.19.
Due to the infinity soft limit in their default configs, and AFAIK no tests to catch a regression of losing the support to respect an explicit soft limit from the system. As stated, I've raised a bug report there so that they'll be aware of this problem.
Before they set infinity, they used to default configure the limit to 2^20, roughly a million (thousand times less). Which wasn't as severe (in my own experience some software could take 1 second to initialize, but under infinity soft limit it would take 70 minutes from all the overhead).
There's been activity discussing reverting back to 1048576 soft + hard limit. This will help the majority of cases, but I was wanting to push for a soft limit of 1024, as there are some reports of this limit still being too high causing some software to need close to 1GB more memory than needed or taking over 10 seconds to initialize.
Lowering the hard limit too much introduces it's own problems (software that needs a higher limit cannot raise above what containerd has a limit). Requiring 2^30 as the hard limit is absurd though just to use a standard 1024 or smaller soft limit than the hard limit.

Thanks.  This sounds to me like something to handle in containerd configuration.

This sounds to me like something to handle in containerd configuration.

I understand that.
Could you please answer the question I raised in each prior comment?:

Can containerd still know the original soft limit and restore that value? Or is it lost by the time the limit is raised implicitly?

Are you suggesting that instead of the system RLIMIT_NOFILE soft limit being usable, now containerd (and other Go software) can only support lowering the soft limit internally through some configuration? (file / CLI arg / ENV var)

How does a Go program opt-out of this behaviour (if it's possible), so that it acts like releases prior to 1.19? (inheriting and using the soft limit assigned outside of the binary).
I'll relay that information to the containerd bug report, and for readers landing here it would better document to Go devs how to handle that too.
The Go 1.19 release notes were not very clear on this beyond:

One impact of this change is that Go programs that in turn execute very old C programs in child processes may run those programs with too high a limit.
This can be corrected by setting the hard limit before invoking the Go program.

The hard limit is set, and this advice is regarding select() by lowering the hard limit to the desired soft limit... which prevents such a child process from creating any children that would want to raise a soft limit to a higher hard limit.
I had to look at the source os/rlimit.go to discover that soft limit would be respected if the hard limit was raised to infinity / fs.nr_open (EDIT: not actually supported):
// Some systems set an artificially low soft limit on open file count, for compatibility
// with code that uses select and its hard-coded maximum file descriptor
// (limited by the size of fd_set).
//
// Go does not use select, so it should not be subject to these limits.
// On some systems the limit is 256, which is very easy to run into,
// even in simple programs like gofmt when they parallelize walking
// a file tree.
//
// After a long discussion on go.dev/issue/46279, we decided the
// best approach was for Go to raise the limit unconditionally for itself,
// and then leave old software to set the limit back as needed.
// Code that really wants Go to leave the limit alone can set the hard limit,
// which Go of course has no choice but to respect.
func init() {
	var lim syscall.Rlimit
	if err := syscall.Getrlimit(syscall.RLIMIT_NOFILE, &lim); err == nil && lim.Cur != lim.Max {
		lim.Cur = lim.Max
		adjustFileLimit(&lim)
		syscall.Setrlimit(syscall.RLIMIT_NOFILE, &lim)
	}
}

So what is software like containerd to do?

EDIT: Actually.... after looking at that source snippet above again, I must have slipped up from tiredness (bug report filed around 9pm). I can't reproduce the infinity hard limit prevents soft limit from being raised. I likely mixed up the terminal tab with my SSH session into a machine with containerd built before Go 1.19..

Can containerd still know the original soft limit and restore that value? Or is it lost by the time the limit is raised implicitly?

I don't know of a way to do that, no.  A program can lower the soft limit, of course, but it doesn't have currently have a way to know what the soft limit was originally.  We could add something but it's not yet clear to me that that is necessary.  Right now you are conveying information to container by setting the soft limit.  But there must be other ways to convey information to containerd.

TL;DR: Without a way to restore the behaviour pre-1.19, instead mandating config to workaround it... should I raise a bug report in this repo? Or all downstream projects this affects must be aware of it and accommodate support via other config means, whilst including disclaimers to sysadmins that soft limits are no longer supported?

We could add something but it's not yet clear to me that that is necessary.

Right...so this is a regression introduced by Go 1.19?

Software built with Go that does run child processes are unable to support a well known and used standard of configuring appropriate soft + hard limits for workloads via RLIMIT_NOFILE (software distributed like containerd has supplied init configs, like for systemd containerd.service that support this via LimitNOFILE).
Go has decided to completely break that, requiring any software that needs a lower soft limit to either:

Lower the hard limit instead, preventing child processes from being able to use anything higher if they need to, while ensuring that any need for lower soft limit of 1024 is applied on the relevant child processes.
If needing distinct soft vs hard limits, the Go program developer must now implement support internally, likely requiring some form of configuration (file, CLI arg, ENV var, etc). Something that was already standard and fairly reliable external of the software being run.

I understand this change with Go 1.19 was for those not informed about being able to raise the soft limit to the hard limit (which I agree is a bad UX problem to run into on both fronts):

Users of software built with Go that shouldn't need to worry or know about these limits, and if software breaks, lower the hard limit instead.
Go devs - Intended to make their software better by avoiding a common EMFILE issue, especially on macOS, based on guarantees that their program likely didn't need the default 256 / 1024 soft limits, so should avoid the implicit penalty.

Now that implicit penalty is delegated to larger more complex software built with Go with no opt-out option available. These projects tend to be slower moving due to release cycles and broad platform support / needs. In particular containerd is a dependency to multiple other projects, also affected in the same way, and this is at a lower level of the stack for devs that it affects on their local systems, not only production.
The users affected, must now:

Try to figure out where the problem is coming from.
Trace it down to the limits (as with the soft limit being too high, you don't get an appropriate error, but instead abnormalities often from third-party software putting heavy pressure on CPU / memory)
Discover where this config issue has happened (this has been an issue prior to Go 1.19 due to default LimitNOFILE=infinity supplied by containerd)
Add a lower soft limit, and observe it has no effect. Learn about various other sources that could impact that, or distro specific changes, etc. Possibly at this point, they'll discover it's a problem with Go 1.19, but mind you this is just one change over the years that complicates what is going wrong (so on some systems it is not easily reproducible).
Or they don't get that far and manage to use a lower hard limit instead without any issues of a soft limit being higher than 1024. Not everyone can do this, the high limit needs to be sufficient to support all child containers / processes needs as well.
While this issue persists, they must find alternative workarounds (you can provide explicit configuration/args to run your containers with lower limits, or do so within the container to run processes with lower limits). It's just a bit absurd to enforce that when needed because something that was functional and agnostic to the executable no longer works like it should (admins/devops must also be aware of this now).

Right now you are conveying information to container by setting the soft limit.
But there must be other ways to convey information to containerd.

This was a standard way to convey that information that Go 1.19 chose to break.
Before Go 1.19, you could convey this same information to your Go program the same way. You'll find other software that additionally adds config to support conveying that information a different way, but this was not desirable anymore for Go 1.19 which chose to inverse the situation.
I use Docker personally, but a quick glance shows containerd as providing an API for projects like Docker to communicate over. I am aware of Docker having some daemon config related to these limits and will investigate, but this would likely mean any other client of containerd would need to add support for the same.
This isn't an issue that applies to just containerd either. It seems a bizarre stance to insist it's ok to break this support without providing opt-out. I understand why it was decided to raise the soft limit implicitly, and I fully support that, but that should not break software that properly supported / used RLIMIT_NOFILE, requiring each to workaround it without a way to know what the soft limit was intended to be, all consumers of that software likewise must adjust configuration accordingly.

Does this affect anything other than containerd?

Does this affect anything other than containerd?

I imagine it applies to any project doing similar process management? How many of the projects exist and if they have alternative config to support lowering the soft limit for the processes they run as children, I don't know :man_shrugging:
Some popular projects that may be affected:

https://github.com/ochinchina/supervisord
https://github.com/aptible/supercronic
https://github.com/go-task/task

They have much smaller communities in comparison, so likelihood of bug reports about it would be lower.
Additionally:

In most environments the issue should be less severe as the default hard limit since 2019 with systemd is 2^19 (524288).
The reason Docker and containerd are more prone is because they supply .service files for systemd that set LimitNOFILE=infinity, which raises that hard limit to 2^30.
Debian based distros opt-out (via build flag) of systemd raising the fs.nr_open limit being raised from default 2^20 to 2^30. They do this because of a bug with PAM that would without explicit config for a limit on login sessions, raise it to infinity, which for whatever reasons has not been addressed AFAIK.

I'm not saying this kind of problem is entirely the fault of Go. Other software that raises the hard limit to infinity really shouldn't be doing that (it was more relevant prior to systemd v240, but lingers). It's less of a problem when the soft limit isn't also infinity, but that's now irrelevant when Go 1.19 is involved.

While a saner hard limit like 2^19 or 2^20 should minimize the issue, some software will still allocate more memory than it would be expected to (hundreds of MB) or on lower end hardware still stall if performing syscalls multiplied by that limit (like a common daemon pattern during init).
In some situations if this affects a CLI tool or something within the shell environment startup, it may also be poor UX if it incurs several seconds of delay each time. How likely that is, I'm not sure, but it's likely difficult to troubleshoot to this as the cause and track it down to something Go did.
Losing the ability to control the soft limit via the OS support for doing so isn't great if one must now be mindful of this gotcha, and each time investigate and possibly lookup how each affected project supports configuring this in it's own special way.

I am just a user and probably exaggerating the problem. If more users chime in affected by other projects, or the devs of those projects express concern, perhaps only then should any action be considered.

Does this affect anything other than containerd?

This effects everything that calls exec.Command

Quoting the blog post which prompted the proposal in the first place:

If said program you hack on forks off foreign programs, make sure to reset the RLIMIT_NOFILE soft limit back to 1024 for them. Just because your program might be fine with fds >= 1024 it doesn't mean that those foreign programs might. And unfortunately RLIMIT_NOFILE is inherited down the process tree unless explicitly set.

(emphasis mine.)

@corhere Thanks for the pointer.  That makes sense to me.
@cpuguy83 Do the changes in https://go.dev/cl/476096 and https://go.dev/cl/476097 fix the problem?  Thanks.

@ianlancetaylor I'm using https://github.com/cpuguy83/test-go-rlimits to test this and not seeing the value reset.

@cpuguy83 Thanks.  Your program uses syscall.Exec, which is uncommon compared to syscall.StartProcess which is used by the os and os/exec packages.  I didn't consider syscall.Exec, so thanks for trying it.  I just uploaded a new version of https://go.dev/cl/476097 to fix it.

@ianlancetaylor Thanks! This change works well.
Tried with both syscall.Exec as well as exec.Command().Run()


List plugin in nx plugin registry

We're looking into moving our project to NX.
One of the points that we had doubts about how we would be able to solve it was our firebase functions.
This plugin has solved it brilliantly, it has given us everything we need and then some.
Thank you for that.
Is there a reason that the plugin is not listed in the Nx Plugins Registry?
https://nx.dev/extending-nx/registry
I'm sure a lot of people would be helped by this and find their way quicker here.

Hi @LanderBeeuwsaert , thanks for this feedback, its good to know folks find the plugin useful.
And yes, I've been meaning to add the plugin to the Nx community list for a while. Will do that when I get a moment. 👍

We are now listed in the Nx Plugin Registry! 🎉

@simondotm well then it's time to close this :-)


'unable to resolve module 'fs' from 'location'' in react-native crna

I've installed alasql in my create-react-native-app project in npm. I include this line at the top of my class
import alasql from 'alasq'
I get this error when trying to run in expo
"Unable to resolve module 'fs' from '[project_path]\node_modules\alasql\dist\dist\alasql.fs.js': Module does not exist in the module map or in these directories:..."
But the files are clearly there in the node_modules folder, so I am confused. Thanks!

You might want to try to do a
'[project_path]\node_modules\alasql\dist\dist\alasql.js'
?

Did this solve it?

sorry, that was a typo. there is only a single \dist directory. i still get the error

You might want to try to do a
'[project_path]\node_modules\alasql\dist\alasql.js'
with no .fs in the end

Woops - accidently closed...

Related to #913

@jeresun Does https://github.com/agershun/alasql#use-webpack-and-browserify help you out?

I'm also trying to use alasql in React Native. I see that in dist/alasql.js the fs related code is commented out, but there's still one require('fs') at line 3114? Seems like the RN packager sees it and blows up.
Commenting out exports.main made it work for me.

Wooooowwww - you are so right!

The require('fs') does not present itself in the minified version...
Can you refer to alasql.min.js instead?


transport: Add pactor support

Documentation and information regarding communicating with a pactor modem is needed.
Maybe bluetooth interface should be a priority?

Paclink-unix has this capability:
http://sourceforge.net/projects/paclink-unix/files/?source=navbar
Perhaps studying the code from that project could be of some use.
I would be very happy to help test when this is implemented.

Thank you!
Was was not aware of the similarity between an AX.25 TNC and Pactor interfaces, so I've justed assumed that paclink-unix's wl2kserial was for AX 25.
This will be very useful indeed.
Testing will be much appreciated when implementation is done. I'll keep you posted.

I'm not sure if it's applicable or not, but another Idea you might see in that project is providing an interface to a standard E-Mail client.

Ahhhhh but I think I discovered another way to do winlink2k without
paclink. BPQ.
Here is the downloads page for BPQ:
http://www.cantab.net/users/john.wiseman/Documents/Downloads.html
On there you can find the executables for windoze and Raspberry Pi.
Here are the instructions for installing on the Rpi:
http://www.cantab.net/users/john.wiseman/Documents/InstallingLINBPQ.htm
Note that there are differences for auto-starting on Debian Jesse vs.
Wheezy.
Here are more notes on the installation process, including links to
configuration file.
http://ag6qo.com/QOpilinbpqNotes.html
You can download this as a place to start if you like.
It's got more ports and capabilities than you'll need. More than likely
you'll need only two ports, the PACTOR one and the Telnet one (you'll need
telnet if you want to do control/configuration over your LAN). I've also
got an AXIP port, two 2m AX25 ports, and one 1.25m AX25 port.
You can also find more notes on the main configuration screens here:
http://ag6qo.com/BPQsysopGuide.html
You can use firebird or something else for a client 😀
--
Andy Kopacwww.linkedin.com/in/andykopac
http://www.linkedin.com/in/andykopac

@akopac:
Although I value your insight, this is an issue tracker for wl2k-go and not a general forum for discussing various winlink software. Please keep comments on topic and related to this project. Maybe you could re-post this on linux-hams or debian-hams.
@NAHANNIV:
Paclink(-unix) is a nice approach to interfacing between winlink and your favorite email client. I may write a client like that in the future, but for now I'll keep it simple and stick with the web ui. wl2k-go is organized a set of libraries that I hope developers some day will use to develop awesome cross-platform winlink software. But in the mean time, I'll continue working on cmd/wl2k (the command line/web ui client) and focus on a good and rich API for the libraries.

Back to topic:
Has anyone tested the wl2kserial.c from paclink-unix with an P4dragon DR-7800? Will it work?

Sorry Martin.  The comment came through nail and I didn't realize I was
replying through a forum.
On Tuesday, January 5, 2016, Martin Hebnes Pedersen <
<EMAIL_ADDRESS>wrote:

@akopac https://github.com/akopac:
Although I value your insight, this is an issue tracker for wl2k-go and
not a general forum for discussing various winlink software. Please keep
comments on topic and related to this project. Maybe you could re-post this
on linux-hams or debian-hams.
@NAHANNIV https://github.com/NAHANNIV:
Paclink(-unix) is a nice approach to interfacing between winlink and your
favorite email client. I may write a client like that in the future, but
for now I'll keep it simple and stick with the web ui. wl2k-go is organized
a set of libraries that I hope developers some day will use to develop
awesome cross-platform winlink software. But in the mean time, I'll
continue working on cmd/wl2k (the command line/web ui client) and focus
on a good and rich API for the libraries.
—
Reply to this email directly or view it on GitHub
https://github.com/la5nta/wl2k-go/issues/4#issuecomment-168935094.

--
Andy Kopacwww.linkedin.com/in/andykopac
http://www.linkedin.com/in/andykopac

No problem Andy :)

Quick update on this topic: linbpq may have GPL licensed code for communicating with a P4dragon on their "special baudrate".

I'll cross-post part of what I wrote in several Posts on https://github.com/la5nta/pat/issues/40 in hope that it may help...
First off, there's a lot of good information regarding Pactor controllers on the SCS website, http://www.scs-ptc.com/en/Downloads.html . According to their material all PTC models II and up have essentially the same set of commands (as far as I could tell they're identical over bluetooth and serial/USB connections), with the newest models having some extensions for Pactor 4 support. This would mean that SCS PTC II and up should be a reasonable initial target for Pactor support, with older models and the Timewave TNCs falling into the 'nice to have'-category, which would essentially require adding two new transports: Pactor 2 for narrowband operation and Pactor 3 (which automagically turns to Pactor 4 on a P4 in its default compatibility mode) for wideband operation. Older PTC models as well as the PK-232 and DSP-232 may be interesting targets at a later stage.
Anyway, I could well be missing something, so feel free to tear into what I just wrote.

See https://github.com/la5nta/pat/issues/40#issuecomment-366433776. I'm closing this issue since we are keeping the ptc driver in a separate repository for now.
Re-open when it's time to merge https://github.com/harenber/ptc-go with this project.


Fix license

Somehow I ended up with the staged-recipes license instead of the gdspy license in the original PR.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Per-process and per-container directories are no longer necessary

I don't think there's any state in these directories that isn't also in gcs memory. We can stop using these directories and simplify a lot of code.

Do you mean in runc? We do use this for example with --pid-file. Not sure we can actually remove these unless I am missing something.


Debug issue with provisioning node when teleport is enabled

This PR:

adds/changes/removes etc

Testing
Description on how cluster-cloud-director can be tested.

[ ] fresh install works
[ ] upgrade from previous version works

Other testing
Description of features to additionally test for cluster-cloud-director installations.

[ ] check reconciliation of existing resources after upgrading
[ ] X still works after upgrade
[ ] Y is installed correctly

Checklist

[ ] Update changelog in CHANGELOG.md.
[ ] Make sure values.yaml and values.schema.json are valid.
[ ] Update /examples if required.

Trigger e2e tests

/run cluster-test-suites

Closing this as the issue has been resolved and no further debugging is required.


this.doc.getTextDimensions do not return any height under typescript.

HI,
my code:
const dim = this.doc.getTextDimensions(strArr, { maxWidth: 170 });  const heigth = Math.ceil(dim.h) - 8;
In Visual Code Studio, the .h is displayed in red.
ng serve create follow error:
ERROR in src/app/invoice/services/invoice-print.service.ts:117:46 - error TS2339: Property 'h' does not exist on type '{ x: number; y: number; }'.
117                 const heigth = Math.ceil(dim.h) - 8;

Yes, and I fixed this in #2848. As I commented on the other issue (#2845), you can workaround this issue by adding a @ts-ignore comment to the line until the fix is released. The code will work at runtime, despite the error.


[cPP PUBLIC REVIEW]

What is the location of the document where the comment is made?
Section 2.2, End of third paragraph.
Comment Type.
S = Substantial: a comment or issue significant enough to warrant a possible objection if the change (or a similar objective) is not met.
What is the comment? Please describe.
The statement about SoC makes it sound like the TOEs must be SoCs, not just that they could be.
Describe the proposed solution/edit
Suggest deleting “are integrated into a System on Chip (SoC) and as such”.

Change the whole paragraph to something like this below (wordsmith the bullets)
Some examples of a DSC could be:

A DSC may be comprised of a single embedded component within a device, such as a Secure Enclave Processor (SEP) or an SoC,
a multi-component system comprised of a software layer and several hardware components (which may be discrete or embedded), such as a Trusted Execution Environment (TEE).
Other configurations are possible, with the key point being the DSC is embedded within a larger system and is not a discrete component.

These dedicated hardware/software components are isolated components of a larger physical package. <> below shows a block diagram of a typical example of a DSC TOE with all of its internal components.


Notify me before the secrets expire.

As a SA user,
I would like to have a warning/banner on the admin portal and/or an email notification a few months before my secrets expire,
So, I can renew them and avoid downtime for my customers.

Using the KV expiry
https://learn.microsoft.com/en-us/javascript/api/%40azure/arm-keyvault/secretattributes?view=azure-node-latest#@azure-arm-keyvault-secretattributes-expires
try attributes.expires


Very poor and outdated blog template which does not match with default template

Here how looks like default (not blog) generated middleman template ($ middleman init my_new_project):
.
├── source
│   ├── images
│   ├── javascripts
│   │   └── site.js
│   ├── layouts
│   │   └── layout.erb
│   ├── stylesheets
│   │   └── site.css.scss
│   └── index.html.erb
├── config.rb
├── Gemfile
└── Gemfile.lock

In contrast, here how looks like a blog template ($ middleman init my_new_blog_project --template=blog):
.
├── source
│   ├── 2012-01-01-example-article.html.markdown
│   ├── calendar.html.erb
│   ├── feed.xml.builder
│   ├── index.html.erb
│   ├── layout.erb
│   └── tag.html.erb
├── config.rb
├── Gemfile
└── Gemfile.lock

It looks poor and outdated. LATEST COMMIT WAS 3 YEARS AGO https://github.com/middleman/middleman-templates-blog . I personally spend a lot of time trying to realize why my generated template is different than in official docs https://middlemanapp.com/basics/directory-structure/ .
I can create a PR to update a blog template, if Middleman maintainers would like to merge it. Thanks.
Additional information

Ruby version: 2.6.1
Middleman version:  4.3.2
Middleman Blog version: 4.0.3
OS version: Linux Ubuntu 18.10

To this repo: https://github.com/middleman/middleman-templates-blog


Swift 4.2 compatibility

As of the upcoming official Swift 4.2 release, this PR incorporates the changes needed to support 4.2.
Before the official release, I would recommend to merge this PR to a dedicated Swift 4.2 branch, which I am not able to do :)
I did not bump version, though, as I think you have a better understanding on how you want to version DynamicBlurView.
Hope that makes sense :)

Hey @KyoheiG3,
just wanted to bump this. Is there a chance this will be merged anytime soon? My library https://github.com/Orderella/PopupDialog depends on it and I would love to keep it updated. If you are not maintaining this library anymore, please give me shout.
Thanks, mate!

Hi @mwfire
Thank you for your awesome PR!!

@KyoheiG3 could we get the Podspec version updated so the latest can be pulled? Thanks!

@pushchris I updated just now.
Thanks.

Thanks a lot @KyoheiG3!  🎉🎉🎉


Removed the incorrectly used default credentials in the client config.

There is no default credentials for custom credential usage.

Test FAILed.

Test PASSed.


Code generator broken on develop

Describe the bug
On develop (the 2021.7.27 beta) the code generator is broken with the error "input ordering failed" - however, it appears the expected files are generated anyway.
To Reproduce
Steps to reproduce the behavior:

Build the latest develop
Open any case
Export using shift-F5
Choose any language
See "input ordering failed error"

Expected behavior
The code generator should open the folder where the files were generated rather than throwing an error.
Screenshots

Operating System and Version

OS: Windows
Version: 2021.7.27 (and maybe earlier on develop)

Closed with pull requests #708 and #707


Download your Project

💡 Feature request

Overview and problem statement
Sometimes I will not put my project on GitHub or some other version control scheme and then I need to access and work on it from another computer, so I wish there was a "wrangler download" command that would grab and download the latest version of your project and put it in a folder.

Hey @evanspy1 - version control isn't part of wrangler or workers. I'd recommend using a git based version control scheme locally, and a trusted remote server on github or other provider. We are currently building around github workflows.


Handling of Pull Requests

This project has a few Pull Reqs that are quite old. I would like to suggest a rule that Pull Reqs should be dealt with quickly, be they accepted or rejected, but they should not be left to hang around.
Comments please

Hi @zkessin, I agree with your suggestion.
I am interested in this project even if I am out of the game in this period. I think that it is not easy for @krestenkrab to approve pull requests right away because this project is not in his priorities and mind context switch among projects is not easy at all.
@krestenkrab what can we do to help you in the approval phase?

@krestenkrab would you be interested in having a few of us help?
the zeromq community has a good set of rules that can be adopted for how to grow triq http://rfc.zeromq.org/spec:22 (though I think leaving the license as is would be good)

Reasonable suggestion if a proper dev process (review and branching model) is used, in order to avoid a chaotic or unstable master branch.

take a look at what I posted for a model, the 0MQ folks have done very well with that model.

That's a very heavy model for fixing responsiveness issues. Also I think someone summed it up as "merge first, ask questions later"? Probably referring to Maintainers SHALL NOT make value judgments on correct patches.
A much better model would be the original git model. Kresten could get one or more trusted contributor to handle the PRs, merge them in their own fork and then submit the update to this very repository. At this point Kresten just has to take a quick glance and click merge in the large majority of the cases.

Changing culture can be heavy, yes. However we've found that merging rapidly gives new contributors the incentive to learn and stay. It's worked very well in dozens of projects now. The only drawback seems to be some vulnerability to trolls, though this is easily managed, it turns out.
If you're seeing PRs sitting unmerged, due to lack of time to review them, I'd definitely check out C4, and ask the zeromq-dev list (mostly users of ZeroMQ, so critical of any faults in the process) how they like the process.

The real issue is that I would like to add some enhancements to Triq, but am not going to do so unless I have some confidence that Pull Reqs will actually get merged

Hello @zkessin, I saw your invite and am wondering if you could explain a little more about it, like whether you talked about it with Kresten and what are your plans for it? Thanks.

Folks, I'm somewhat hung up .. so if one of you cool erlangers want to co-administer this you're most welcome.

I want to manage the open-triq branch under the zerom

I hope we can keep triq under Apache license.

It will stay under the same licence

Readme changed to make the licence clear

Given the size of Triq, a dual branch model is sufficient to allow:

quick merges of good patches
keeping a stable master
merging to master on schedule, assuming it's in a regression-free state

Also due to Triq's size there's no need for collecting topic branches into next and merge only stable topics.
So, if we change the project settings to merge pull requests to a staging branch (with immutable history), we can have co-administered merges of patches.
Kresten has offered to assign permissions as required, so I don't see a need for a separate project.

The use of a single master branch for all work is aggressive, yet it has
proven successful in multiple projects now, of all sizes and maturities.
Merging to master forces errors into public view sooner, and puts the
economic onus on contributors, rather than maintainers. It has reduced the
error count in our projects dramatically, and made it much easier for new
participants to join.
On Mon, Mar 9, 2015 at 4:56 PM, Tuncer Ayaz<EMAIL_ADDRESS>wrote:

Given the size of Triq, a dual branch model is sufficient to allow:

quick merges of good patches
keeping a stable master
merging to master on schedule, assuming it's in a regression-free
state

Also due to Triq's size there's no need for collecting topic branches into
next and merge only stable topics.
So, if we change the project settings to merge pull requests to a staging
branch (with immutable history), we can have co-administered merges of
patches.
Kresten has offered to assign permissions as required, so I don't see a
need for a separate project.
—
Reply to this email directly or view it on GitHub
https://github.com/krestenkrab/triq/issues/47#issuecomment-77881331.

I would agree with that. I do not see much point in a branch or even less a fork. This project just needs someone with time to review and merge changes.

Well ideally what it needs is a few people who can collectively deal with pull requests. I don't want a bunch of pull requests to pile up because one person goes on holiday or gets swamped at work etc

Just wait for Travis - CI to run the tests before you merge a pull request

We had a few significant breakthroughs in the ZeroMQ process. One was to
split off reviewing PRs from merging them. We simply do not do blocking
reviews. This sounds insane yet produces better code. To merge a PR takes
just a quick sanity check, and even that is redundant. If someone breaks
master, that is significant and useful data. And fixing the break is good
learning, either for the contributor, or for others.
This only works if you (a) use a single branch, (b) promote contributors
aggressively to maintainer and (c) have tools for regulating bad actors
(thus a well written contract of sorts).
On Mon, Mar 9, 2015 at 5:19 PM, Zachary Kessin<EMAIL_ADDRESS>wrote:

Well ideally what it needs is a few people who can collectively deal with
pull requests. I don't want a bunch of pull requests to pile up because one
person goes on holiday or gets swamped at work etc
—
Reply to this email directly or view it on GitHub
https://github.com/krestenkrab/triq/issues/47#issuecomment-77886476.

I also like the idea of having it under an organizational ownership, not @krestenkrab 's personal account

This project barely has any tests, relying on Travis or similar is suicidal at best.

well we can add more, but it might as well pass the tests that it has

@hintjens, how do you avoid introduction and subsequent fixing of bad APIs, which means more maintenance overhead due to extra deprecations and compat code, without code reviews?

With libzmq we also had few test cases. We enabled Travis, and said,
"breaking existing test cases is a reason to revert (or not merge) a
patch", and with this incentive, new contributors added a lot of test
cases. This was very positive.
However I don't usually wait for Travis before merging. Like I said,
breaking master is good data.
On Mon, Mar 9, 2015 at 5:28 PM, Zachary Kessin<EMAIL_ADDRESS>wrote:

well we can add more, but it might as well pass the tests that it has
—
Reply to this email directly or view it on GitHub
https://github.com/krestenkrab/triq/issues/47#issuecomment-77888631.

@tuncer here's my latest proposal for that: http://hintjens.com/blog:85
Basically you allow APIs to evolve naturally, and you tag them RAW, DRAFT, STABLE, LEGACY, RETIRED depending on use. This gives you a tool for fixing design errors (during RAW and DRAFT), while not breaking user space (STABLE onwards).
The underlying change theory is, deliver code rapidly to real people, and allow them to express irritation in the form of pull requests rather than issues. Done right, you get a smooth and fast cycle of change that iterates through refinements until APIs and internals are good, and stable, and the result sits for a year or two before being superseded by a better abstraction. You then make a new draft, and start to deprecate the old APIs (e.g. remove from documentation). The library can support them for long, the cost is usually low.

anyone know how to get travis-ci to work with a new organization? It does not turn up in my travis-ci screen

You need to sign into Travis with the credentials of that organization, I
think.
On Mon, Mar 9, 2015 at 5:46 PM, Zachary Kessin<EMAIL_ADDRESS>wrote:

anyone know how to get travis-ci to work with a new organization? It does
not turn up in my travis-ci screen
—
Reply to this email directly or view it on GitHub
https://github.com/krestenkrab/triq/issues/47#issuecomment-77892544.

Ok, so who here likes the idea of using the ZeroMQ Model, please leave a +1 comment so we can get a sense.
Obviously if there are any questions then ask them

@hintjens, how do you convey what stage an Erlang function is at to a random consumer of the API?

I would guess as part of the documentation.
Anyway I'm not too interested in a process that breaks master all the time, I like me git bisect.

@zkessin, I can understand why a separate org is preferred, but:

the org name reads as if krestenkrab/triq is somehow "closed"
the org name is too long for my taste

As krestenkrab/triq is under a personal (not company) profile, I don't mind keeping the canonical url unchanged, but I'm okay with a separate org that has a better name :). It has to be worth it, though, as it will take a very long for users to realize the new url, to name one problem.

the problem was that the name triq was not available, if you have a better name for the org i would be happy to take suggestions

I think the model depends on the project, and how many qualified contributors are on call to unbreak master.
I totally understand the benefits of the proposed model and can relate to the issues the other models impose on everybody, but merging everything that doesn't look totally broken to master doesn't appeal to me in the proposed form. First of all, you need enough qualified contributors on call to unbreak the branch in a matter of hours max. That means, a project short of contributors suddenly is in need of more contributors. Second of all, doing no review of interface changes means more often than not the maintainers will have to do the cleanup or refactoring rather than the patch author, who may never reappear, and the maintainers may have to guess and fill in the blanks, or not have access to certain operating environments. Finally, in the merge-quickly scenario it becomes more important that CI includes the project being tested against as many existing users (projects) of it as possible, which usually requires a nightly run.
So, I think there has to be a healthy middle-ground between merge-anything and pending-for-review-since-last-year.

I totally understand the benefits of the proposed model and can relate to the issues the other models impose on everybody, but merging everything that doesn't look totally broken to master doesn't appeal to me in the proposed form. First of all, you need enough qualified contributors on call to unbreak the branch in a matter of hours max. That means, a project short of contributors suddenly is in need of more contributors. Second of all, doing no review of interface changes means more often than not the maintainers will have to do the cleanup or refactoring rather than the patch author, who may never reappear, and the maintainers may have to guess and fill in the blanks, or not have access to certain operating environments. Finally, in the merge-quickly scenario it becomes more important that CI includes the project being tested against as many existing users (projects) of it as possible, which usually requires a nightly run.
So, I think there has to be a healthy middle-ground between merge-anything and pending-for-review-since-last-year.

@zkessin if a separate org is the way to go, I'm sure we'll find a better name. Let's ignore the name for now.

ok, we will leave it as @open-triq if we think of a better one later we can change it

I'll throw in a few more comments:

the process is meant to, and does, increase the number of contributors
it reduces the workload on existing maintainers (really, that's why I made it, as maintainer)
patches are reduced in size (1 problem, 1 change) so are easy to correct or revert
it's merge-anything yet combined with significant improvement on change size and focus
you can use that latter part alone, with some, not all, the benefits
using an org lets you apply fork/merge systematically, no special rights for anyone

Anyhow, this ain't a sale pitch, just material for thought. :)

Hey all, is the issues tracker meant to be closed for open-triq/triq?

No, I will fix that

@krestenkrab, what's the plan?

@krestenkrab ping?


Use the larger x64 macOS runner for release builds

Closes https://github.com/astral-sh/uv/issues/6766

Down to 10m from 25m.


Fix AtomicTechIncJunkyards install

Oops, this is actually an error, not an intentional change. The author uploaded the wrong mod.


only show section if name translations has changed

Issue #: /bcgov/entity#5176
Description of changes:

was showing blank section with line before
also, don't show "changed" chip on summary page

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

Also please check the unit tests :)

Done & done


Add a 'sortLeaves' options

By default, leaves are sorted. This is done so to simplify the multiproof process.
When building a multiproof, all the leaves being proven must be in the same order as they appear in the tree. This means that when verifying a multiproof, the contract will have to order the leaves in an order that matches their position in the tree. Best practice is to order the leaves of the tree such that the smart contract can replicate that order without knowledge of the tree, and thus verify the multiproofs.
However, there are also usecases where the tree is constructed iterativelly, from unsorted leaves. See:

https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4758
https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3617
That is a case that the current library cannot serve, because the leaves are reordered by StandardMerkleTree.of.

In order to support that usecase, I'm proposing we add a option object to StandardMerkleTree.of. Leaves will be sorted by default to replicate existing behavior. Disabling the sorting addresses the need of the usecases describe above. Note that since these usecase use full/complete tree, the reversal part (done by the core) is irrelevant.
In ay b more difficult for contracts to verify multiproofs for trees constructed without leave sorting. This may not be a major drawback though. In any case, it is still possible to verify such multiproof, as long as the caller of the contract can force the ordering of the leaves that must be proven.

If a tree has 2**n leaves, with n the depth of the tree, then all leaves are at the same level. In that case, reverting the order of leaves (or not) does not change the resulting root. That is because the hash used is symmetric.
The fact that the leaves are reversed only affect trees where all leaves are not at the same level. In that case, the reversal part affects which leaves are at which level. In that case reverting the leaves (or not) changes the overall tree.
Note that before merging we plan to update the README to document that feature, and its consequences.


init methods in layers/embeddings.py make reference to argument that is not in the argument list

The init methods for both Embedding and WordContextProduct set self.normalize = normalize, but normalize is not an argument of the __init__ method. This causes the IMDB (LSTM) example not to work.

Just fixed this.


nshlib: Rename CONFIG_SYSTEM_NSH_SYMTAB to CONFIG_NSH_SYMTAB

Summary
Follow up the patch: https://github.com/apache/incubator-nuttx-apps/pull/1350/commits/44b90f584a05c9b52ccc0f0ba6a97cc365ba1298
Impact
Move symbol table config from apps/system/nsh to apps/nshlib
Testing
Need merge together with https://github.com/apache/incubator-nuttx/pull/7330

@pkarashchenko could you merge this simple change?

Seems to be a "breaking change"


optimum inference for summarization

With reference to the blog: https://huggingface.co/blog/optimum-inference, I am able to do this:
from transformers import AutoTokenizer, pipeline
-from transformers import AutoModelForQuestionAnswering
+from optimum.onnxruntime import ORTModelForQuestionAnswering

-model = AutoModelForQuestionAnswering.from_pretrained("deepset/roberta-base-squad2") # pytorch checkpoint
+model = ORTModelForQuestionAnswering.from_pretrained("optimum/roberta-base-squad2") # onnx checkpoint
tokenizer = AutoTokenizer.from_pretrained("deepset/roberta-base-squad2")

optimum_qa = pipeline("question-answering", model=model, tokenizer=tokenizer)

question = "What's my name?"
context = "My name is Philipp and I live in Nuremberg."
pred = optimum_qa(question, context)

I need to do similar inference for summarization, for the following code:
from transformers import AutoTokenizer, AutoModelForSeq2SeqLM
tokenizer = AutoTokenizer.from_pretrained("sshleifer/distilbart-cnn-12-6")
model = AutoModelForSeq2SeqLM.from_pretrained("sshleifer/distilbart-cnn-12-6")

I get the following error:
>>> from optimum.onnxruntime import ORTModelForSeq2SeqLM
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'ORTModelForSeq2SeqLM' from 'optimum.onnxruntime' (/datadrive/shilpa/work/virtual_environments/venv_hf_optimum/lib/python3.9/site-packages/optimum/onnxruntime/__init__.py)

https://huggingface.co/docs/optimum/main/en/pipelines - mentions "text-generation" as one of the supported tasks,  "summarization"  i assumed comes under this category. Am I right?

Thank you for using Optimum! Currently, the supported model class for text-classification looks to be ORTModelForCausalLM, see:
https://github.com/huggingface/optimum/blob/6aa47f96be4644acdfbaa2a006b891ae1bad5474/optimum/pipelines.py#L58-L62
Interestingly, the transformers' AutoModelForSeq2SeqLM is loading at the end of the day ...ForConditionalGeneration, see here and here. Looks like this is not yet supported in Optimum.
However, looks like the text-generation task is mapped to ...ForCausalLM models, see here and here.

Hey @ShilpaSangappa,
We currently only have support text-generation or rather speaking Decoder models like GPT-2, GPT-Neo, GPT-J. But we are working on adding support for Seq2Seq models to be able to use Encoder-Dedocer models and tasks like summarization and translation.

@fxmarty @philschmid Thank you for the clarifications.

@fxmarty @philschmid Thank you for the clarifications.

@Ierezell sorry not yet. I ll try to update this issue if we have concrete timeline for it.

@ShilpaSangappa @Ierezell the text2text-generation, summarization and translation pipelines are finally supported as we merged #199


[Discussion] Apache ECharts 6.0 Feature Discussion

Apache ECharts 5.0 was released in December 2020, and now it's time for the next major version: 6.0!
We are excited to announce that we plan to release Apache ECharts 6.0 in the first quarter of 2025. We have put together a list of features that we intend to include in this upcoming release.
We would love to hear from you about which features you are most excited about and looking forward to using. Please share your thoughts and let us know what you think!
It's important to keep in mind that most of our contributors work on ECharts in their free time, so some features may take longer to implement than others. If you are passionate about a particular feature and would like to help us bring it to life, we warmly welcome you to join our community and contribute to the development of ECharts 6.0!

Great to hear and see the amazing progress.
For us most important would be to get this issue here solved:
https://github.com/apache/echarts/pull/16825 -> There is already a PR and it is really sad to look at these amazing charts and seeing the overlap most of the time.
Less important but would be nice to see it merged at some point: https://github.com/apache/echarts/pull/17579#issuecomment-1557228206
Other issues we would profit from are:
https://github.com/apache/echarts/issues/16744#issuecomment-2072955797
https://github.com/apache/echarts/issues/13759#issuecomment-2003218280
I appreciate the great work you are all doing and happy to contribute further if we see progress on the things we already contributed.
Greetings,
Daniel

@DanielBogenrieder Thank you guys for submitting such excellent pull requests! I apologize if I miss any updates due to the volume of messages; it can sometimes be a bit overwhelming. However, I assure you that I will review these requests soon. :)

I hope this feature can be added： #18157，thanks！

I hope this feature can be added： #18157，thanks！

I saw that you made some attempts to implement this feature. How about making it to be a pull request?

Those are some great features you have on list. Would it be possible to revisit https://github.com/apache/echarts/issues/19182 ? Thanks!

请问echarts有交流群吗

Could you add a sizeMap similar to the visualMap component to map sizes? For example, would it be more intuitive to use a sizeMap for the legend of the point sizes in the bubble plot?

There could be a react component version.

I would really like to see the hierarchical/grouped bar chart like mentioned in these issues: #4902 #13839 #18923 #19441
Unfortunately three of those issues don't seem to be posted as feature requests, but I think the use case is quite common as I also needed it for one of my projects that use Apache ECharts.

I think fixing the tree collapse problem is long overdue: PR #18491 for #17266 and others.

It would be exciting to have a reactjs component officially

Organization and position tree chart is very useful the Issue 9405 - Requested 6 years ago

Two enhancements that I think would be pretty simply and quick to implement are #20200 and #18121.
A bit more effort would be involved in a longstanding issue that I commented on in 2022:
https://github.com/apache/echarts/issues/15585#issuecomment-1306059279_

We need to have a better way to apply number formatters globally. Some languages don't format numbers as in English, and it is too much work to replace the default formatter in all components.
This issue has been reported in some issues already: https://github.com/apache/echarts/issues/8294 https://github.com/apache/echarts/issues/4180
I think we have some ways to achieve that:

Have per-locale configurations and make the addCommas function use that as a source
Global user-provided formatter function
Use Intl.FormatNumber or .toLocaleString() using the current echarts locale

The locale files already have some configuration for thousand separators, at first I thought it was used for number formatters but seems that is not the case.

Could you add a sizeMap similar to the visualMap component to map sizes? For example, would it be more intuitive to use a sizeMap for the legend of the point sizes in the bubble plot?

This sounds to be an interesting feature. One challenge may be, what happens if some of the bubble sizes are to large to be displayed in the legend.

@andregamma There is a valueFormatter option. Do you think this may save the problems you mentioned?

It'd be great to see https://github.com/apache/echarts/issues/16099 (better support for time-based bar chart binning).

Hello, thank you team for all the hard work - ECharts 5 made some huge progress and I look forward to v6!
for v6 I would personally love to see an official schema for all the JSON options available.
#16427 has already been requested.
I think it's common to generate the ECharts JSON from a backend service - in java/python/.NET/etc, and it would be awesome to have a common schema to be able to generate against. There are already projects for specific languages linked in the docs, eg Echarts-Java or Pyecharts, but sometimes they get left unmaintained.
Other than that - I would support the design token idea proposed by @Ovilia in #20202 and any other ways to simplify changing similar settings across multiple series types etc.
There are a lot of options available (a great thing) but sometimes the interface to find/change them is challenging.
thanks again!

Thanks for working on ECharts.
#19941 would be nice to have. I was looking at improving a single axis scatter plot with inspiration from https://nightingaledvs.com/ive-stopped-using-box-plots-should-you/ but it seems like jittering the scatter points is currently not possible.

请问echarts有交流群吗，qq 群或者微信群

noticed that echarts 5 already have some excited changes like datasets, visualMap, series. still, I think we can go father in version 6

could we really have a visual scale to replace {visualmap.show:false}, scale of grammar of graphics is useful for some situation, it can convergence config option and make more possibility. and still, can we rethink xAxis/yAxis. it mixed axes style, value scale, data source. not so friendly for users
datasets group filter is very useful, cause we do need a new way to quickly set multi series
option.grid is very important for charts facet, could we optimize help doc or demo?

@Ovilia
thx for all amazing works

It's so cool to hear that you work on a new major version - many thanks already! :heart: :pray:
One - actually quite small but very helpful - feature I really miss and would like to suggest for 6.0 is adding a time zone config option per time axis (see https://github.com/apache/echarts/issues/14453). In case you display data in different time zones, this would be really helpful.

Maybe fix too the label z-index with lots data ?
I re-open the issue because I did a reproducible project with this issue, it seem it happen when there is too much data. I put a multiplier in line https://github.com/apache/echarts/pull/1, when multiplier = 1 it works:
echarts multiplier data = 1
When multiplier is 2, it double the data, the z index in label issue happen:
echarts multiplier data = 2

We've scoured the issues board for a solution to trigger the closest series item on hover (see https://github.com/apache/echarts/issues/15080). We'd love if this feature could be prioritized!

@kateEcobb, did you try already useCoarsePointer ?

Feature : To able to color the background rulers (xAxis, yAxis), actually I use graphic option.

Oh my god if you Echarts developpers you can add API support for Vertical Zoom !!! Actually there is only horizontal zoom.
In the company where I work, railway industry I have echarts UI with amazing graph tool, the vertical zoom control is really a miss 👍

请问echarts有交流群吗

👀

Oh my god if you Echarts developpers you can add API support for Vertical Zoom !!! Actually there is only horizontal zoom. In the company where I work, railway industry I have echarts UI with amazing graph tool, the vertical zoom control is really a miss 👍

sorry I can control the y Axis with this setup: https://github.com/apache/echarts/issues/20459

Could you add a better support for dected zoom type on onDataZoom event ?
const ondataZoom = (param: any) => {
    const zoomID = param.batch[0].dataZoomId.toString()
    if (zoomID === '\x00series\x001\x000') {
      // zoom Y are handled
      console.log('zoom Y handled', [param.batch[0].start, param.batch[0].end])
    }
    if (zoomID === '\x00series\x000\x000') {
      // zoom X are handled
      console.log('zoom X handled', [param.batch[0].start, param.batch[0].end])
    }
  }

'\x00series\x001\x000' is vertical zoom and '\x00series\x000\x000' is horyzontale,

Could you and a better name for exemple:
if (param.batch[0].dataZoomType === 'y') { // store dataZoom Y values array }
if (param.batch[0].dataZoomType === 'x') {  // store dataZoom X values array  }

Wow, echarts v6, this is amazing news!  Personally I would ask for only 1 thing, that is the only major problem I have with echarts:

the zooming and panning on charts is quite complex (and very cumbersome) to handle.  It should be very simple to enable and disable features with boolean, and we should have a smooth pan and zoom free experience like in the Trading View charts.

I have never figured out how to implement a vertical zoom in my current chart code, and sadly I don't have a rocket science degree...
Please make sure to support React!  Thanks for everything.

There is no graph that supports ellipses

In my work, i use confidence bound chart a lot to do analysis. Currently creating a confidence bound chart using echart is not easy and you could check the official example here: https://echarts.apache.org/examples/en/editor.html?c=confidence-band
While, it is convenience to create such kind of chart using highcharts. You could check the example here: https://www.highcharts.com/demo/highcharts/arearange
Is it possible for echarts to provide this arearange chart type like highcharts does?

Making performance a priority for 'time' axis line charts, particularly when there are many series and when datapoint symbols need to be rendered--currently the entire browser tab crashes quite often even when trying the various sampling options, example: https://github.com/apache/echarts/issues/20022#issuecomment-2536540746
I have tried pulling in the nightly release for v5.6 since there was a optimization added in July (#20161), but the issue is still present

Data sampling in dataZoomSlider: https://github.com/apache/echarts/issues/18754

目前使用dataZoom配置横向滚动条后，在电脑端的Edge浏览器上滑动不了。而且在安卓手机的浏览器上也滑动不了，还容易触发安卓手机的返回，希望这部分功能能得到解决
Currently, after configuring the horizontal scrollbar with dataZoom, it cannot be slid on the Edge browser on the computer. And it also cannot slide on the browser of Android phones, and it is easy to trigger the return of Android phones. I hope this part of the function can be solved

It would be great to add the possibility to run echarts instances inside a web worker in order to not block the main process when working with big amounts of data (1M+) related: #9232

Also using echart with vue ( thanks for the great integration)
This would be great because when loading a dashboard with multiple chart there is often a freeze since data Can load at the same Time.
A ts definition would be great to build my option object !


owo

Puww reqwest

[x] I have read and agreed to the code of conduct.
[x] I have read and complied with the contributing guidelines.
[x] What I'm implementing was assigned to me or was not being worked on and is a somewhat requested feature. For reference see our GitHub projects.
[x] I have tested all of my changes.

Added/Changed
owo
Feature
owo

Even if we do add owo language we're not ready for translations just yet as we're going to be making major changes to the file structure here soon.


Feature: Skip ahead to the next comment or 10 ahead

Potential change for the skip 10:
Skip ahead feature will either go to the next comment or to 10 ahead, whichever is fewer. It allows the comments to be viewed without going through all moves.

That's an interesting idea. I'm a bit ambivalent about the skip 10 buttons, since I only ever use them accidentally, myself, and have been tempted to dispense with them entirely.
We do have buttons to go to the next / previous comment, as shown here:

You can also use alt + ← or alt + → to navigate between commented moves.

Oh, awesome! Didn't see those buttons there. I'll remember that. Thanks!
I don't use the skip 10 either.


Show progress while installing extensions

Testing #177702
I think I am wrongly being asked to install extensions now, but when I do need to install an extension, it would be nice to show a progress bar somewhere while this runs

Or if I am going to be waiting for a bit, you might run the progress in a modal dialog or non-modal notification instead of a quickpick

somewhat related: https://github.com/microsoft/vscode/issues/177950
FWIW I did see a progression bar while the extension was installing on Windows


Data source cannot be created

Hi, I just installed this locally to test it and I can't input anything in the setup form (see the screenshot). I tried hardcoding the values of those DOM elements and then clicking "Save and Test" but that also failed.

Is this plugin working as of today? It doesn't seem like that


Eliminate cython in install

Do we need to fix readme?

Do we need to fix MANIFEST.in?

OK! LGTM!


Refactor and clarify event status and start/end date verification

This PR resolves #189. Specifically, it proposes the following changes:

Deprecate the event_status property on the WorkZoneRoadEvent and DetourRoadEvent.
Add deprecation note to EventStatus enumerated type.
Deprecate the start_date_accuracy and end_date_accuracy properties on the WorkZoneRoadEvent and DetourRoadEvent.
Add deprecation note to TimeVerification enumerated type.
Add new boolean properties is_start_date_verified and is_end_date_verified to the WorkZoneRoadEvent and DetourRoadEvent to indicate if the work zone or detour has been confirmed to have started/ended by a person or device in the field or report from a TMC, or similar.
Require either start_date_accuracy or is_start_date_verified.
Require eitherend_date_accuracy or is_end_date_verified.
Update example feeds to use is_start_position_verified and is_end_position_verified and not use event_status, start_date_accuracy, or end_date_accuracy.

See #281 for a similar approach of using booleans that this PR is consistent with.

@j-d-b I thought we discussed at one point but were we planning on still updating the object and enumeration lists in the spec-content README?  Or will we just do this when everything is merged?


When using multiple carets, autocomplete only completes the first one selected

An image says more than a thousand words:

dupe of #16037


Control defaults for user notification

[x] Alerts
[x] Lock PMs by default

Looks like I missed the option "Send warning conversations by default"

'Send warning conversations by default' appears blocked by the FormFiller interacting poorly with Disabler


How to declare owners manually?

Instead of automatically fetching them from the application.

Saw the source code and figured it out.


Configure Container Startup Timeout

Containers like HuggingFace text-generation-inference take a long time to startup because they're pulling down the model which is usually multi-GB files.
This causes the app to time out.
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: C:\Users\luquinta\source\repos\TestAspireDeployment\TestAspireDeployment.AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: http://localhost:15201
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press CTRL-C to stop.
info: Grpc.AspNetCore.Server.ServerCallHandler[14]
      Error reading message.
      System.IO.IOException: The client reset the request stream.
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestPipeReader.ReadAsync(CancellationToken cancellationToken)
         at Grpc.AspNetCore.Server.Internal.PipeExtensions.ReadSingleMessageAsync[T](PipeReader input, HttpContextServerCallContext serverCallContext, Func`2 deserializer)
fail: Grpc.AspNetCore.Server.ServerCallHandler[6]
      Error when executing service method 'WatchResourceConsoleLogs'.
      System.IO.IOException: The client reset the request stream.
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestPipeReader.ReadAsync(CancellationToken cancellationToken)
         at Grpc.AspNetCore.Server.Internal.PipeExtensions.ReadSingleMessageAsync[T](PipeReader input, HttpContextServerCallContext serverCallContext, Func`2 deserializer)
         at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerStreamingServerCallHandler`3.HandleCallAsyncCore(HttpContext httpContext, HttpContextServerCallContext serverCallContext)
         at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerCallHandlerBase`3.<HandleCallAsync>g__AwaitHandleCall|8_0(HttpContextServerCallContext serverCallContext, Method`2 method, Task handleCall)

Provide a way to enable containers that take a long time to start up.
To repro in Aspire, add this to AppHost project.
var hf =
    builder.AddContainer("hf-generation", "ghcr.io/huggingface/text-generation-inference",tag: "1.4")
    .WithVolumeMount("$PWD/data", "/data", VolumeMountType.Bind)
    .WithHttpEndpoint(hostPort: 8080, name: "generation")
    .WithArgs("--model-id", "HuggingFaceH4/zephyr-7b-beta");

I tried to repro this on latest bits and it seemed to indicate there's an error in your WithArgs call?

Yeah. Good catch. I don't think that's needed in this case so you can still run it without that arg. Updated the repro command

For reference, --shm-size is an arg for docker run itself which we don't support right now (similar to #2737).
I'm trying the repro again now...

Also note, your .WithVolumeMount("$PWD/data", "/data", VolumeMountType.Bind) needs to be changed to .WithBindMount("./data", "/data") with latest bits and to work the way you intended I think (the $PWD just gets taken literally, not interpreted as the current directory).

For reference, --shm-size is an arg for docker run itself which we don't support right now (similar to #2737).
I'm trying the repro again now...

I see. So to clarify docker run args aren't supported but args passed to to the container are. In this case --model-id being something you pass to the container.

Ok I got this working locally on latest (daily) bits.
I had to change your code to the following to ensure the endpoint was registered correctly:
var hf =
    builder.AddContainer("hf-generation", "ghcr.io/huggingface/text-generation-inference", tag: "1.4")
        .WithBindMount("./data", "/data")
        .WithHttpEndpoint(containerPort: 80, hostPort: 8080)
        .WithArgs("--model-id", "HuggingFaceH4/zephyr-7b-beta");

I watched the logs in Docker Desktop and on the Aspire Dashboard and it took about 5 minutes to fully startup:

At that point I opened a terminal and ran the following command:
 curl localhost:8080/generate -X POST -d '{"inputs":"What is Deep Learning?","parameters":{"max_new_tokens":20}}' -H 'Content-Type: application/json'

And got the following reply:
{"generated_text":"\n\nDeep Learning is a subset of Machine Learning that uses Artificial Neural Networks with multiple"}

I could the generation details in the log too:

If there was a problem before it seems it's fixed now, perhaps by the recent change to streaming logs.

Awesome! Is this the right guidance for setting up the latest Aspire?
https://github.com/dotnet/aspire/blob/main/docs/using-latest-daily.md

Yep! Let us know if you run into any issues. Getting the feeds and workload just right can be a little tricky.


[BUG] OIIO sample doesn't exit normally with certain DDS files in Windows

When opening dds_bc* sample images with the following minimal sample the program doesn't exit. Other images do not cause the issue. I only had this issue with Windows build but not in Linux build. It sounds like it could be a threading related issue. It gets stuck after free(pixels); line due to something at read_image().
#include <OpenImageIO/imageio.h>
using namespace OIIO;

int main(int argc, char** argv)
{
auto inp = ImageInput::open(argv[1]);
if (! inp)
  return 0;

const ImageSpec &spec = inp->spec();
int xres = spec.width;
int yres = spec.height;
int channels = spec.nchannels;

unsigned char* pixels = (unsigned char*)malloc(xres * yres * channels);
inp->read_image(0,0,0,-1,TypeDesc::UINT8, pixels);
inp->close();
free(pixels);
return 0;
}

OIIO master 2022 Oct 06 / 28122968e536feb39541c4
Windows 10 (executable and OIIO cross compiled in Linux Debian 10 with mingw)
x86_64-w64-mingw32-g++-posix (GCC) 10-posix 20210110

FWIW I can't reproduce the issue (neither Debug nor Release build type), but I'm using a VS2022-built Windows build of your sample program.
Can you try with a more recent master branch (after Oct 7, i.e. after #3591 was merged)?

It still happens with the latest master branch. I guess I will have to take a look at dds_bc code to try to see what causes the issue.

The first thing I was going to do was ask @aras-p if he could take a look, but he beat me to it!
Does it do this with any other file types? I'm not sure why dds would be any more of an issue than other files.
Something specific to the mingw cross compile? That's way out of my experience area.

I did additional testing and the issue also happens with tif and tx files. Everything else that I tested worked (including png,jpg,bmp,tga,hdr,exr,gif,ico,dpx,rla,pfm).
Of course, it could also be a mingw bug but I've never encountered an issue with it where code compiled but didn't work.
I wonder what dds_bc*, tif and tx files have in common that trigger it.

tx IS tiff
Maybe both dds and tiff are both using the thread pool internally?

Yeah, so far this points to "something something thread pool", since all of those are using OIIO thread pool. But what is the issue, now that's a good question... (I'm trying to figure out how to use this "mingw" thing as we speak, stay tuned...)

FYI you probably want either MSYS2 or Mingw-W64-builds from here: https://www.mingw-w64.org/downloads/ . With the latter you might need to manually compile cmake. I haven't used mingw-w64 in Windows in ages, however. Also, all OIIO deps need to be either recompiled or be dynamic libraries because static libraries from VS won't work.

I managed to build OIIO with w64devkit in Windows as DLL from the same static dependencies and that didn't have the issue. So its probably a mingw bug and not a bug in OIIO. For me this fixes the problem so this could be closed as "not planned".

OK, let's close then. Re-open if you become convinced that there's something we can do on our side to make it better.
We don't "officially" support MinGW (similar to Android, iOS, FreeBSD, etc.), in the sense that none of the main developers use it or are knowledgeable about it, we don't test on it, none of the big studio users need it as far as I know. We just aren't resourced to be comfortable advertising it as being supported. But we know people use it on those platforms, and we've always happily merged PRs from MinGW users to have fixes to make it work. As long as it doesn't break the other platforms, we take the user's word that a PR fixes something on that compiler and incorporate the patch.
That said, if somebody wanted to help set up another Windows CI job in our CI test matrix that was WinGW based, it might help ensure that we aren't casually breaking on MinGW as we add other things and simply don't know if it will work. I wouldn't even know where to start with that project (I can barely keep the Windows CI tests going sometimes, it's just not a platform I work with in my daily life), but would accept a PR from somebody else who sets it up.


i18n for frontend website.

Tell us about your Wish
Add internationalization using something like svelte-i18n and Crowdin
Is your feature related to a bug
No response
Alternatives
No response
Additional Info
No response
Participation

[ ] I am willing to submit a pull request to implement this

Disclaimer

[X] I agree

I agree, this can be aimed at a later release it is currently out of the scope for the current release.

I hope you'll start to open the Crowdin page or something similiar in the future.


Ignore style check for zip strict flag

An alternative of #4917.

Let's put this globally in setup.cfg, with a comment like "requires Python 3.10". For this sort of compatibility stuff, I search "Python 3.x" etc. when dropping support, so I can undo this when needed.

Updated.

Handled in #4922 while I was fixing the docs build too. Missed that you updated this, sorry.


Upload LROSE notebooks

Three notebooks are uploaded.

LROSE basics
Multi-Doppler wind retrieval and an overview of the tornado case
LROSE wind tutorial

Thank you Max for your help :) Enjoy the long weekend!
--
Ting-Yu Cha, PhD
Postdoctoral Fellow
Advanced Study Program
NSF National Center for Atmospheric Research
@.*** @.***>

On Aug 30, 2024, at 7:12 AM, Max Grover @.***> wrote:
** Caution: EXTERNAL Sender **
@mgrover1 approved this pull request.
This looks great to me! Nice work @tingyucha https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftingyucha&data=05|02|Ting-yu.Cha%40colostate.edu|2f48b85fdf384ff56d4408dcc8f56a92|afb58802ff7a4bb1ab21367ff2ecfc8b|0|0|638606203591767621|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|0|||&sdata=k8Ke3hbjzYYHsVwZ4DrzjspRI1fiiO3wBSQWl6IdWGU%3D&reserved=0 and team 👍
—
Reply to this email directly, view it on GitHub https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenradar%2Ferad2024%2Fpull%2F91%23pullrequestreview-2272293077&data=05|02|Ting-yu.Cha%40colostate.edu|2f48b85fdf384ff56d4408dcc8f56a92|afb58802ff7a4bb1ab21367ff2ecfc8b|0|0|638606203591779373|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|0|||&sdata=QwR9pvyIZ9HsJiUvWNia5aDYV3AphABLExKZbs7J7fg%3D&reserved=0, or unsubscribe https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGAV4NUBOJHIGGLC25PO7Q3ZUBVUHAVCNFSM6AAAAABNDE6GISVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDENZSGI4TGMBXG4&data=05|02|Ting-yu.Cha%40colostate.edu|2f48b85fdf384ff56d4408dcc8f56a92|afb58802ff7a4bb1ab21367ff2ecfc8b|0|0|638606203591786808|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|0|||&sdata=N4D9TNGylFW6%2FycNW4GEXFB1exEWKo80GtGpPIaZvUo%3D&reserved=0.
You are receiving this because you were mentioned.

I can take care of that @kmuehlbauer :)

Here too!
https://github.com/openradar/erad2024/blob/7336e345bbe194f01d023a8424b0f498d68c2059/.github/workflows/build-book.yaml#L28
And normally before merge, here too:
https://github.com/openradar/erad2024/blob/7336e345bbe194f01d023a8424b0f498d68c2059/.github/workflows/build-book-pullrequest.yaml#L31

I've pushed a fix so the image can be tagged correct. Fingers crossed!

I've pushed a fix so the image can be tagged correct. Fingers crossed!

Thanks 👍 sorry about that!

No worries. The tagging mechanism is not especially user-friendly. For the CI it might be possible to derive the number from GHA environment, but for the Dockerfile we'll have to make it by hand. So I thought I do not invest much time for that.


Fix 'The pipe is being closed' IOException

Fixed an issue where a 'The pipe is being closed' IOException is thrown when a CMD process doesn't exit naturally from the Control+C sent to it when attempting to stop the process, and is instead force killed after the wait time specified for the stop.

Hi @Mpdreamz
I noticed that you have an open pull request (https://github.com/elastic/elasticsearch-net-abstractions/pull/67) on elasticsearch-net-abstractions to upgrade to the latest version of this package.
This issue causes our Elastisearch tests to fail every now and then, so after getting this PR merged I was also going to submit a PR to upgrade this package on elasticsearch-net-abstractions.
Is there any chance of getting this fix in and then upgrading elasticsearch-net-abstractions directly to the new version?
Thanks

There is! You caught me while I'm on PTO though somit might be a week before I get around to upgrading this across the board.
Thanks for the PR!

Awesome!
Thanks so much for responding during your time off, hope you have a good break.


nomad, vault: buildFlagsArray -> tags

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 132842 at f91178f8 run on x86_64-linux 1

1 package marked as broken and skipped:

nomad_0_12

3 packages built successfully:

nomad (nomad_1_0)
nomad_1_1
vault

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

1 package marked as broken and skipped:

nomad_0_12

3 packages built:

nomad (nomad_1_0)
nomad_1_1
vault


release: update changelog and CONTRIBUTORS

Signed-off-by: Wei Fu<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
Update changelog for 1.0.0-rc2
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
😈
Ⅳ. Describe how to verify it
use CI to check the typo
Ⅴ. Special notes for reviews

lgtm


How to customize trailingIcon widget of FocusedMenuItem?

I want to change trailing Icon as i want, the widget that "trailing Icon" get only "Icon" widget, but i want to add "Container" widget. How can i do that?

Hi,
Thanks for great plugin. I have a similar question. How can I add on Appbar right side icon. Icon has onTab function but it doesn't open the focused menu widget. Any example for this or any idea how can I accomplish this problem. Thanks

I'm closing this issue since we added this feature on PR #19


Release 0.0.3

I guess we can release the v0.0.3 (rubygems)

Thanks for your interest! We are more than happy to know your release request. :)
We will try to do necessary testing before releasing it.

Hi @pimgeek :) something new ?


Remove dead bridging calls for dead parameters

This PR consists of 2 changes:

lazily emit shared witness tables: This avoids emitting synthesized witness tables if they are not needed.

mark all _unconditionallyBridgeFromObjectiveC functions as @_effects(readonly): Read-only lets the optimizer remove such a call if the result is not used.
Note that "readonly" means: no observable write operations. It's okay to allocate and initialize new objects.

rdar://problem/44944094

@swift-ci test

@swift-ci benchmark

Build comment file:
Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Improvement

NSStringConversion
717
0
-100.0%
717001.00x

Code size: -O

TEST
OLD
NEW
DELTA
RATIO

Improvement

NSStringConversion.o
873
793
-9.2%
1.10x

Performance: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

StringWalk
1699
2008
+18.2%
0.85x

Improvement

NSStringConversion
732
0
-100.0%
732001.00x

Code size: -Osize

TEST
OLD
NEW
DELTA
RATIO

Improvement

NSStringConversion.o
938
858
-8.5%
1.09x

Code size: Swift libraries

TEST
OLD
NEW
DELTA
RATIO

Improvement

libswiftCryptoTokenKit.dylib
28672
24576
-14.3%
1.17x

libswiftNaturalLanguage.dylib
45056
40960
-9.1%
1.10x

libswiftNetwork.dylib
172032
163840
-4.8%
1.05x

libswiftXCTest.dylib
86016
81920
-4.8%
1.05x

libswiftAppKit.dylib
86016
81920
-4.8%
1.05x

libswiftCloudKit.dylib
106496
102400
-3.8%
1.04x

How to read the data
The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

Ah, nice!
Is there a way to make @_effects(readonly) automatic in this case, or to otherwise ensure that it is applied to any new _unconditionallyBridgeFromObjectiveC functions that may get added in the future? It'd be a shame for some new datatype to lose out on this optimization just because the annotation was overlooked.

Yes, the compiler could enforce this based on the annotation on the protocol requirement.
I created https://bugs.swift.org/browse/SR-8953 for this.

one quick question however, does this apply to linux bridging as well?

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@phausler good point. Yes, it would make sense to add the annotations in swift-corelibs-foundation as well.

The benchmark output suggests NSStringConversion isn't doing any work anymore. Do we need to modify that test so that it actually performs the conversions? Or maybe there's some other test that covers that, and thus it's a good thing to have this test indicate that the work is skipped when the stores are dead?

I'll fix the benchmark in a follow-up PR


Motion Sensor Not Refreshing

When the motion sensor is triggered, it's not showing in app. But when I reload app, the motion sensor triggers. And why after the motion sensor triggered, it shows that all time, even if it doesn't triggered.

Must be fixed in last release as input pin are monitored on both EDGE changes.

Fix and tested in the last release. 0.2.5.
Motion sensor are now like other digital inputs and could be used with same parameters.

thanks for fast solution, waited 5 months

Are you serious ???
Everything was OK until last week were an update broke it. But it seems you just don't take the pain to test it.
Did you pay anything for that ? Or did you try to update and test the code to participate ?
Please go away and avoid open duplicate issues.

No complains, and I'm not NodeJS developer, so I can't help you with contributing your project. You distributing your project as free and open source, so I don't need to pay.

I'm not NodeJS developer either but that does not stop me from proposing things instead of waiting for it to come to me for free.
Yes I'm sharing (not distributing) for free so you don't need to pay but I do not have to provide fast or any technical support either (but I do it for respectful people). And your answer suggests that you expect a faster one. But the issue was already fixed.
If you had bothered to look in the current issues, you would have had your answer and avoid me some duplicate tasks.
And if you really waited 5 months, may you could revive the topic of look further. But the fact is you're not really waiting. You are just an oportunist.


Customizable SetDuration for Valve Accessory

Thanks for this amazing plugin—it’s been a real treat for my HomeKit setup!
I have a feature request for the Valve accessory. It would be awesome to have the option to customize the SetDuration characteristic with a minimum, maximum, and step size.
For example, I use a valve to water my balcony planters, and being able to set times e.g. between 1 and 5 minutes (in 1-minute steps) directly in the Home app would be super helpful.
It would also save me from accidentally turning my balcony into a miniature Venice every time I forget to stop the water :)
Thanks for considering this!

Thank you for your suggestion, but I don't fully understand what you're asking.
The configuration already has a duration field as you can see from the screenshot below. Per the spec, you can set a maximum duration of 1 hour and the unit is seconds, so 3600 secs max - I need to update the field description on that.
If you set the duration to zero, then you have turn it off manually.
Maybe I need to change the name if it is confusing?

Sorry, I just re-read your request ... let me try again!
In the Home app, when you open the valve accessory settings you see a selection widget to select the valve run time:

The available duration times are 15 seconds, 5 minutes, 10 minutes, etc. If I understand correctly, you would like to see the options as 15 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, 10 minutes, etc. Is this correct?
Unfortunately, the plugin has no control over what the Home app displays. The app is notorious for providing options that are less than ideal. A suggestion is to install the Eve app, it's a free app. It doesn't exactly offer what you are looking for, but it does offer a few additional duration times: 10 seconds, 30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes, etc.

Thank you for your response and for the suggestion to use the Eve app - I appreciate the tip!
Yes, I would like to change those options shown in the Home app to include durations like 15 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, 10 minutes, etc. as the defaults of the Home app are truly often not ideal.
I believe the plugin could override these defaults by implementing something like the following:
import { CharacteristicProps, Formats, Perms } from 'homebridge';

const durationProps: CharacteristicProps = {
  format: Formats.UINT32,
  perms: [Perms.PAIRED_READ, Perms.PAIRED_WRITE, Perms.NOTIFY],
  minValue: 0,
  maxValue: 300,
  minStep: 60,
};

this.service.getCharacteristic(this.platform.Characteristic.SetDuration)
  .setProps(durationProps)
  .onSet(this.handleSetDurationSet.bind(this))
  .onGet(this.handleSetDurationGet.bind(this));

However, TypeScript isn’t exactly my mother tongue, so this might need some adjustment, but I hope it conveys the idea.
This approach could potentially override the default behavior, allowing custom durations.
If there’s a way to integrate such changes into the plugin, it could address these less-than-ideal defaults effectively.
Looking forward to your thoughts on that.

That's an interesting suggestion.
The code snippet you provided modifies the properties of the SetDuration characteristic, as defined in the Homekit Accessory Protocol:
      unit: Units.SECONDS,
      minValue: 0,
      maxValue: 3600,
      minStep: 1,

I will definitely look into it, however it may take a little while for me to get to it, as I am working on some other fixes at the moment.

Awesome! Sure, please take your time