exit full screen toggle(middle button in the right corner) stopped working

VSCode Version: 1.4.0
OS Version: Windows 10

Steps to Reproduce:
1.Open VSCode
2. change the size
3. press maximize button
4. Toggle - nothing happens

Does this issue occur when all extensions are disabled?: Yes/No
Yes

Is it about actual Full screen (F11 or Zen Mode) or just problems with Maximize/Restore button?
Probably duplicate of #84343 (as mentioned in https://github.com/microsoft/vscode/issues/84798#issuecomment-554131186)
Could you try Insiders build (https://code.visualstudio.com/insiders/) to see if this issue is fixed there?
See https://github.com/microsoft/vscode/issues/84343#issuecomment-554202848

/duplicate https://github.com/microsoft/vscode/issues/81102


Missing documentation for failMsg option

Subject says it all.

Also I'd suggest using more descriptive name, e.g. errorMessage

And also add httpStatus that will be returned to user. By default the proxy returns 407 but e.g. if it's invalid hostname, it should return 502 Bad Gateway.

failMsg is now described in README, custom error can be done using RequestError


All APIs that accept Buffer should also support ArrayBuffer

I’m building a pubsub demo on js-ipfs and I’m not using a framework or a compiler to try and keep things simple to understand, but I’m currently blocked on this line
https://github.com/libp2p/js-libp2p/blob/de84ee473c5b095134a20361f0c0a808405083d2/src/pubsub.js#L62
Requiring the Buffer API means that you must use a compiler, since Buffer isn’t a browser API and there isn’t a polyfill that works without a compile chain.
IMO, any API that requires a Buffer should also accept an ArrayBuffer and just convert it using the built in polyfill.

So up until now all those APIs that make use of Buffer objects are not available for browser builds? Could the use of a lib like https://github.com/feross/buffer be an appropriate solution?

All APIs now accept Uint8Arrays so this is complete.


Error cartographer ROS

I new in ROS and i tried to prove the slam method cartographer with turtlebot3 (MELODIC) and i have a problem with the map, i did not make anything code all is the demo for the installation

The console show me this:
Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: canTransform: target_frame map does not exist.. canTransform returned after 0.1 timeout was 0.1.
I can see the robot and the laser scan but not generated a map. Can i help me??

Do you have robot_state_publisher node running?
<node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher" output="screen">       <param name="publish_frequency" type="double" value="50.0" />   </node>


Removing alt-section class and use nth-child instead

Instead of having to add alt-section class to every other section it's automatically gray (every other).

Merged!


More ergonomic API for constructing sockets

I started out wanting to be able to bind a socket to a given address (for the purposes of using a particular network interface) before connecting, and quickly discovered the standard library does not provide methods for doing so. I then found net2::TcpBuilder, which does provide this feature, but found the API somewhat less ergonomic than I would have liked.
@sfackler pointed out that RFC 1461 (after the failed RFC 1158) pulled in a couple of changes from net2 into the standard library, and @seanmonstar that net2 is a "Desired out-of-band evaluation" in the libz blitz, so I figured I'd send some feedback in the hopes that eventually something like TcpBuilder might land in the standard library too.
My suggestions follow below. I'd be happy to file a PR, but @sfackler suggested that given the backwards-incompatibility of these changes, filing a ticket first for discussion would be a good idea. Some of these build on the Builders enable construction of complex values (C-BUILDER) section from @brson's Rust API guidelines, whereas others are just because I like them better. Thoughts and feedback very welcome!

The methods on TcpBuilder that modify the socket should all take &mut self, and return that &mut in their Result. This is because, while it is technically true that a socket can be mutated safely from multiple places, it leaves the consumer of the API confused about whether there's a difference between the original builder and the returned one. For instance, it is not clear just from the API (nor from the resulting code) that tcp and tcp2 are the same socket, bound to the same port in the following code:
let tcp = TcpBuilder::new_v4().unwrap();
let tcp2 = tcp.bind("<IP_ADDRESS>:4000");

Using &mut self is also more semantically accurate, since it indicates that we are in fact modifying the underlying socket.

The methods on TcpBuilder that listen, connect, or otherwise "initiate" the socket, should take self, not &self. The current API implies that you can re-use a builder to construct a second socket after calling listen or connect on it once, but this is not true. The code will panic if you try to do this, presumably because a single socket cannot be re-used. In theory, the builder could remember the configuration, and lazily create and configure the socket when needed, which would enable this kind of API, but I'm not sure that's really better. I think it's fairly rare that you'll want to re-use a socket configuration.

The change above brings us back to the first point about &mut self vs &self. @brson's post says that:

Under the rubric of making easy things easy and hard things possible, all builder methods for a consuming builder should take and returned an owned self.

Which suggests that we should in fact make all the builder methods take self. This unfortunately combines poorly with the fact that our methods can fail, and thus return Result<Self, ...>. If a method fails, you'd like to still be able to recover the builder, which is tricky if self was consumed. Maybe @brson can provide some insight here?

This is a more controversial one, but it might be that we should provide a SocketBuilder rather than a separate TcpBuilder and UdpBuilder. Under the hood, that's what the Berkeley Socket API provides, and it's unclear you want the distinction here either. Instead, you could imagine SocketBuilder being parameterized by UDP/TCP, which would still let us only expose the TCP related methods for TCP sockets. I personally think this would make the API more readable, and it would avoid the complete duplication of methods between the implementations. Along the same lines, I'd prefer to see V4/V6 be an enum passed to new, but I feel less strongly about that particular point.

@seanmonster pointed out that this is unlikely to break existing code, since current implementations must already only be calling the finalizing methods once (since any other use panics). Making the methods take &mut self will also likely require minor or no changes, since they are unlikely to be using the aliased & pointer anyway. Moving to self will require more changes to user code, as the original element will no longer be available, but if the regular one-line builder pattern is used with unwrap (which is unfortunately common), everything will keep working as usual. Dealing with the error cases will be trickier though, and we need a story there.

Here's the original discussion with @seanmonstar, @habnabit, and @sfackler from #rust:

jonhoo: why on earth do all the methods on TcpBuilder in net2 take &self
jonhoo: and return Result&TcpBuilder:
jonhoo: that's a really weird builder pattern
seanmonstar: jonhoo: cause you can mutate the socket without a mutable reference
jonhoo: true, but it's a strange pattern
jonhoo: what does the return value even mean?
jonhoo: for bind() for example, do I need to be using the returned value?
jonhoo: or the original?
jonhoo: or is the original somehow not modified?
sfackler: jonhoo: they're the same pointer
seanmonstar: that was because since all those operations could return an error (they're adjusting options on the socket, not something in rustland)
_habnabit: jonhoo, the return value is for chaining
seanmonstar: it wasn't desirable for you to call build() and get a EINVAL, and be left wondering "well crap, which of those methods had the invalid argument"
jonhoo: sure, but the classic way to do this is to then take `self`
sfackler: jonhoo: no standard library builders work that way iirc
jonhoo: being left with both pointers is weird, because it's not *clear* that they're the same
jonhoo: taking `self` is unambigious
_habnabit: jonhoo, how do you get the socket back out then?
seanmonstar: jonhoo: https://github.com/brson/rust-api-guidelines#builders-enable-construction-of-complex-values-c-builder
seanmonstar: jonhoo: you'd then need it to return ResultTcpStream, (io::Error, TcpStream):
jonhoo: hmm
jonhoo: I see
seanmonstar: otherwise its lost
jonhoo: right right
jonhoo: I still think I'd prefer it taking an `&mut self` even though it's not technically necessary, just to indicate that you are actually modifying the socket (and thus that you can use either the original or the returned)
jonhoo: just like in brson's pattern above
seanmonstar: its cause TcpStream is an odd duckling, and can be mutated through &self
jonhoo: mmm
seanmonstar: its safe to copy from a stream back onto itself
seanmonstar: so io::copy(&tcp, &tcp) works
jonhoo: oh, sure, I realize that, but for the builder pattern specifically it seems strange to not take &mut self even though *technically* you can
jonhoo: also, are you allowed to connect multiple times from the same builder?
jonhoo: because the current API allows that, right?
seanmonstar: nope, looks like it wil panic if tried again
jonhoo: yeah, I don't think the underlying sockets allows that
seanmonstar: i agree that the semantics of the api feel very not-normal
jonhoo: I guess *technically* the builder could allow that by lazily creating the socket on connect
jonhoo: which is the case for brson's example, and the reason his Command's build takes &self
jonhoo: but somehow it feels cleaner to me, especially for TcpBuilder, to take `self`
jonhoo: since there is just *one* socket that you're constructing
jonhoo: and then I think it follows that it should also be &mut
jonhoo: even though the syscall API allows &self
jonhoo: it'd be a pretty serious breaking change though
seanmonstar: would it though? the most common case is likely building it all at once
jonhoo: ah, you think most code actually conforms to the stricter api
jonhoo: yeah, probably
jonhoo: though it would require people to place `mut` in a couple of places if we made the methods `&mut self`
seanmonstar: i dunno, im sure you'd get push back if you did
seanmonstar: but i'd be silently rooting for you
jonhoo: haha, probably
jonhoo: thanks :p
arete: me too, I remember the API being pretty terrible =)
jonhoo: maybe I'll file a PR to revamp it and fix up the docs
jonhoo: worth filing an issue first to discuss you think?
sfackler: jonhoo: I would
sfackler: that builder is very old and barely used
sfackler: conventions around it are not super clear
sfackler: jonhoo: we moved a bunch of stuff from net2 into libstd a year or so ago, but left those builders out of it because we weren't super sure about the way they should work
jonhoo: sfackler: mmm, fair enough. okay, I'll file a ticket discussing this

I guess this is cc @alexcrichton too — you're everywhere in Rust land!

Thanks for the report! There's definitely quite a few constraints on this API, and I agree that we have yet to thread the needle quite well enough just yet.
The original intent of the decisions in this crate were:

Using &self instead of self was chosen in order to align with Command, allowing ergonomic configuration of a builder over time without having to consume and rebind it.
Using &self over &mut self was chosen because this builder doesn't actually require a mutable reference (e.g. the socket under the hood is safe to use concurrently)
Methods returning a Result was chosen because each stage's error could be acted to differently. For example if one address failed to bind you could choose a fallback address to bind to, but if the original socket creation failed then that may be fatal.
The TCP/UDP split was intended to align with libstd, and also provide a place for the extension traits for various socket options to live. That is, many socket options for TCP don't make sense for UDP and vice versa.

So given all that, I'm not personally 100% wed to the current API. I'd be totally fine moving over to &mut self as it's just downright more flexible in the long run. I would prefer to not, however, take self by value because it makes configuration over time more difficult, for example methods like this. I'm not personally a huge fan of the panic-on-double-listen semantics, but in practice it doesn't seem to cause any problems and it allows methods to ergonomic be chained if it doesn't consume self.
Given that, what do you think?

I agree that &mut self -> Result<&mut self> is the most flexible solution, and would be happy to make that the interface. It does directly conflict with the recommendation in C-BUILDER, but having worked with self-consuming channel senders in futures, I agree that not consuming self makes a lot of things nicer. That said, I do think that the finalizers (e.g.,  TcpBuilder::connect) should consume self. This would not affect chaining (since you can't chain across a finalizer anyway), and would entirely avoid the double-connect panics.
As for TCP/UDP, I'm a bit on the fence here. I agree that for established connections,, the methods you can run are different, but I don't know that this is true prior to calling listen/bind/etc., which is what the builders are for. I don't have a particularly strong opinion here though, and the current scheme is also fine (assuming it shares the underlying code eventually anyway).
So, in total, my preferred API would be (taking #45 into account):
impl<Proto> SocketBuilder<Proto> {
    fn new_v4() -> Result<Self>;
    fn new_v6() -> Result<Self>;

    fn ttl(&mut self, ttl: u32) -> Result<&mut Self>;
    fn only_v6(&mut self, only_v6: bool) -> Result<&mut Self>;
    fn reuse_address(&mut self, reuse: bool) -> Result<&mut Self>;

    fn local_addr(&self) -> Result<SocketAddr>;
    fn get_reuse_address(&self) -> Result<bool>;
    fn take_error(&self) -> Result<Option<Error>>;
}
impl SocketBuilder<Tcp> {
    fn bind(&mut self, addr: SocketAddr) -> Result<&mut Self>;
    fn listen(self, backlog: i32) -> Result<TcpListener>;
    fn connect<T>(&self, addr: SocketAddr) -> Result<TcpStream>;
}
impl SocketBuilder<Udp> {
    fn bind(self, addr: SocketAddr) -> Result<UdpSocket>;
}

I'm not entirely sure what purpose the to_tcp_* methods serve, but wonder if they should be implemented using TryInto instead?
It's sort of weird that bind has very different semantics for UDP vs TCP sockets. For TCP, it just binds the address and returns the builder, whereas for UDP you no longer have access to the builder after calling bind(). I'd suggest making bind return Result<&mut Self> for both, and then have a separate build(self) method for SocketBuilder<Udp>.
I'm also not sure about the naming of some of these methods:

take_error seems strange; does it acually "take" anything?
ttl and only_v6 seem like they should have a set_ prefix?
get_reuse_address vs local_addr should be consistent about prefix

Oh so one point with consumption as a final step (but &mut self in the middle) is that then chaining no longer works in the case of:
TcpBuilder::new_v4()?.bind("...")?.listen(n)

The return value of bind is &mut TcpBuilder where listen would then require a move of the internal contents :(.
In general we've avoided type state in the past, and I'd be hesitant to use it here. In general while it does deduplicate the implementation a little bit I've found it doesn't tend to help consumers (e.g. why would a consumer be generic over SocketBuilder<T>?). Do you think there's a use case for consumers though?
The to_tcp_* methods are currently mostly just there to enable more fine-grained construction, such as when operations have been manually performed or will be continued out of band, but the previous configuration is needed.
One thing that I've personally concluded over time is that using a builder basically just isn't worth it. Instead I feel like we should just have struct Socket and be done with it. It has tons of methods for everything and then you do everything manually basically. Essentially this crate would just become a "rusty" socket API.
All of my own personal previous attempts at least have ended up being unergonomic in one way or another in some situation. Having just a straight up Socket, however, would fix this as the expectation level would just be different for the level of ergonomics :)
Out of curiosity, what do you think of that?

I think that's a great idea. In a way, that's what the API above starts to approximate (including being protocol-agnostic) if you remove the builder parts. I like it. You could arguably also get rid of the <Proto> generic, and instead just panic if you try to connect or listen on a UDP socket?

Heh so I actually intended on doing this a long time ago, and finally got around to it! I haven't documented much but do the APIs here seem reasonable?

That looks pretty good! I think I'd also like to see a way to convert into TcpStream, TcpListener, and   UdpSocket for interoperability, but having the full low-level interface is nice.

Oh bah looks like they didn't show up in the docs but the conversions are the via into

Can I poke the authors to take a look at this again? The lack of backlog on UnixListener is a serious deficiency as it keeps one from using std with services that get more than minimal throughput.

@njaard I would recommend using socket2: https://docs.rs/socket2/0.3.11/socket2/

Thanks for the fast response! I already found it, but since I'm using tokio I also have to propagate that through mio! It's disappointing that backlog was forgotten throughout the entire ecosystem.

You can turn a socket2 Socket into a std UnixStream and a std UnixStream into a tokio UnixStream.

For anyone else who may stumble upon this: The following definitely changes the socket backlog to 4096:
    let path: &str = ...;
    use socket2::*;
    let socket = Socket::new(Domain::unix(), Type::stream(), None).unwrap();
    socket.bind(&SockAddr::unix(path).unwrap()).unwrap();
    socket.listen(4096).unwrap();
    let socket = socket.into_unix_listener();
    let incoming = tokio_uds::UnixListener::from_std(socket, &tokio_reactor::Handle::default())
      .unwrap()
      .incoming();

    let s = hyper::Server::builder(incoming)
      .serve(new_service)
      .map_err(|e| eprintln!("error: {}", e));


File corrupted in chunk 2, expected page length 4..512, got 167772161 [1.4.197/6]

Getting this issue while doing this in a thread in android
 public void saveAll(List<Employee> employees) {
        this.repository = NitriteDB.initialize().getRepository(Employee.class);
        for (Employee employee : employees) {
            repository.update(employee, true);
        }
 }

Having said that following line is giving the same error when used in class constructor
this.repository = NitriteDB.initialize().getRepository(Employee.class);

I am closing this for inactivity. If you still face issue, provide me a reproducible code.


Website: blog/docs style fixes

set line height to 1.75rem for paragraphs for both blog and docs. (i had it sent to 150% of 18px which is 27, and 1.75rem is the closest round number at 28px—this gives the text enough room to breathe.)
small caps h5 letter spacing 3%
links 600 weight, with teal-600 #007C9E

MOBILE

docs mobile: header sizes should be using mobile sizes (h1 should be 2rem, blog subtitle h3 should be 1rem)
top nav mobile: need to hide "Treehouse" text (show icon only) so both "Documentation" and "Blog" fit in the top bar
docs mobile: need to add sidebar menu
mobile typography: margins need to be adjusted

h2, h3, img, p:last-child: 8px/0.5rem bottom margin
h2, h3: 12px/0.75rem top margin
p+p: 8px/0.5rem bottom margin

web/static/style/design.css


Makefiles need to allow optimized builds

Reported by hankin on 17 Oct 2000 18:02 UTC
Currently "-g" is permamently ON.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/174

Comment by<EMAIL_ADDRESS>on 21 Oct 2003 20:16 UTC
Moving from the<EMAIL_ADDRESS>user to the<EMAIL_ADDRESS>user.


Simplify smoke tests suite to shorten the test period

Description
Simplify the smoke test suites. Some previous discussion: https://github.com/omgnetwork/releases/issues/5#issuecomment-668434382
closes: https://github.com/omgnetwork/releases/issues/2
Changes

Split transfer tests to multiple test files so we can use a single one in smoke test
Add simpleStartStandardExitTest
Edit the smoke test to be without challenge test and simplify the transfer and SE tests.
trigger processExits to clean up things in the queue before test to be a good test citizen

Tests
run npm run ci-min-smoke-test against sandbox and took around 20 mins

Tried a few npm audit fix and even npm audit fix --force locally. Seems like a dependency of dependency from lerna is causing an issue but no fix is merged and released yet: https://github.com/lerna/lerna/issues/2606

Tried a few npm audit fix and even npm audit fix --force locally. Seems like a dependency of dependency from lerna is causing an issue but no fix is merged and released yet: lerna/lerna#2606
───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ dot-prop                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=5.1.1                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ lerna [dev]                                                  │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ lerna > @lerna/version > @lerna/command > @lerna/project >   │
│               │ dot-prop                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1213

cc. @nicholasmueller @kevsul @jarindr what's your opinion on resolving this?

maybe we can update to only fail CI withhigh security issue.


Initial trigger for openSUSE:Leap:16.0:Images

we're not yet doing openSUSE:Leap:16.0 as that project contains no installable image. This will have to be solved separately

I think that sombody like Andrii Nikitin needs to tweak the trigger scripts. As @nilxam is sure that there will be a lot of harcoded stuff for Leap.

Let's merge this asap, we'll be fiddilng with details afterwards

@jlausuch I think we're ok to merge here, but I'm not entirely sure if there's something missing, as I don't see leap showing up in the CI

https://github.com/os-autoinst/openqa-trigger-from-obs/pull/254 is more correct and a complete change.

Closing in favor of #254


Added post processing script

ebi-ait/dcp-ingest-central#241
Test plan

Download project directory
Run script locally
Verify that the new files are conforming to spec in the ticket

Note: Tested against test projects from staging Terra staging area (specified in the ticket)

couldn't add @amnonkhen yet as reviewer

It took just some time but he's got the permissions now :)

It's still not modifying the filenames for the analysis_files
It's modifying the metadata in the file_descriptor but the filenames remain the same
New Checksums need to be generated

There actually was no error!
LGTM

Please just comment directly on the code, if you have suggestions.


[IOTDB-2239] Hompage Sidebar Rearrangement

Description
Fixed a bug that homepage doesn't show correctly.

This PR has:

[ ] been self-reviewed.

[ ] concurrent read
[ ] concurrent write
[ ] concurrent read and write

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods.
[ ] added or updated version, license, or notice information
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious
for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold
for code coverage.
[ ] added integration tests.
[ ] been tested in a test IoTDB cluster.

Key changed/added classes (or packages if there are too many classes) in this PR

Coverage decreased (-0.02%) to 67.445% when pulling 0d915e8be8a33ced95b4545a6b0780a1b0bb03b4 on trin1t:library-udf-docs into 131167d2d50f70dc42ca68bd82c7cb5cdedd5840 on apache:master.

Coverage decreased (-0.02%) to 67.445% when pulling 0d915e8be8a33ced95b4545a6b0780a1b0bb03b4 on trin1t:library-udf-docs into 131167d2d50f70dc42ca68bd82c7cb5cdedd5840 on apache:master.


[EmbeddedAnsible] Fix job_plays for API

The Service UI makes use of the API to fetch both .stdout and .job_plays together in a single call.  Without this definition, .job_plays is not recognized as a valid attribute to fetch, and the following error is returned from the API call by the ServiceUI:
{
  "error": {
    "kind":"bad_request",
    "message":"Invalid attributes specified: job_plays",
    "klass":"Api::BadRequestError"
  }
}

This fixes that error, though a follow up is most likely going to be necessary in manageiq-ui-service since it seems like they are striping out the html data we are sending them, so the formatting looks like garbage...

(Note:  In the above screenshot, the "Plays" is zero, but that is because I am using an older version of the appliance where the job_plays attribute wasn't implemented.  That should be fixed in the latest release.)


Overview pane Exchange information table overlaps with System information in not maximised state

Windows 10

The latest Git master branch contains the new look of the wallet. It has not been fully tested on all OSes yet. It appears in this case the default Windows 10 fonts are enlarged by 20% or so and this causes the problem. It needs to be fixed in a way that makes it flexible/not dependent on font scaling.


discrepancy between persistent and non-persistent topics

Describe the bug
When subscribing to a persistent topic Pulsar checks if the topic exists and fails to subscribe if the topic does not exist.
When subscribing to a non-persistent topic Pulsar does not check if the topic exists. The subscription succeeds but when the topic is created later on and messages are published the subscriber does not get them.
A similar problem exists when subscribing to persistent or non-persistent wildcard topics. The subscription succeeds but when topics are created later on that match the wildcard and messages are published the subscriber does not get them.
Expected behavior
Also fail to subscribe for non-persistent topics.
A better solution would be to allow subscriptions to non-existing topics and automatically subscribe to them the moment they are created.
This is even more interesting for wildcard topics where you want to subscribe without knowing if the topic exists.
Environment:
Pulsar 2.7.0
Pulsar 2.7.1

The issue had no activity for 30 days, mark with Stale label.

Closed as stale. Please create a new issue if it's still relevant to the maintained versions.


 NEEDS IMMEDIATE ATTENTION!

Nevermind. I found a workaround.

What was the work around?


gitlab: 17.2.2 -> 17.2.4

Description of changes

https://about.gitlab.com/releases/2024/08/21/patch-release-gitlab-17-3-1-released/
https://gitlab.com/gitlab-org/gitlab/-/blob/v17.2.4-ee/CHANGELOG.md
Fixes CVE-2024-3127
Fixes CVE-2024-6502
Fixes CVE-2024-7110
Fixes CVE-2024-8041

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

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

5 packages built:

gitaly
gitlab
gitlab-ee
gitlab-pages
gitlab-workhorse


Increasing Frame Rate?

@izzytwosheds
This library has saved me a significant amount of time. I was on the verge of diving deep into the wormhole of implementing the MediaCodec from scratch, so I truly appreciate your assistance.
I have a query that might seem unusual, but I'm hopeful you might have a solution or at least guide me in the right direction.
Here are the scenarios I'm looking at:
Input: 1920x1080 resolution at 30fps, h264 (video/avc)
Output: 1280x720 resolution at 120fps, h264 (video/avc)
Input: 1920x1080 resolution at 60fps, h264 (video/avc)
Output: 1280x720 resolution at 120fps, h264 (video/avc)
I understand the frames required for 120fps don't actually exist in the input. However, is there a way to auto-multiply or duplicate the existing frames to achieve this?
Separately, I also have this scenario which I believe is achievable. I'll be working on it over the next few days:
Input: 1920x1080 resolution at 30fps, 40-second video, h264 (video/avc)
Output: 1280x720 resolution at 120fps, 10-second video, h264 (video/avc)
For the latter scenario, I assume that by simply setting (MediaFormat.KEY_FRAME_RATE, 120) I can get the desired result. But I'm still not certain about how to approach the first two scenarios mentioned above.
Thanks once again for all your help!
Best regards,
Joe

Apologies for delayed response. Happy that you are enjoying LiTr!
Can you elaborate why you need to increase the frame rate? As you said, effectively we will have to duplicate frames, so we will be increasing file size without any improvements in visual quality. That is the reason LiTr currently supports only frame rate reduction. But I am happy to learn more about your use case.

Sorry for the delay response been doing a lot of business travel.
Unfortunately have an issue where some camera manufactures output a 120 FPS video at 30 FPS and 4x time length (mainly DJI drones and cameras) so need to downscale and time remap so the video is 120 fps at 1x time. currently doing ffmpeg to update the container, but though it would be faster and better to have this all done in LiTr.

Hello @izzytwosheds
I thought I would not have had issue with this, but I seem to be struggle also with this senario:
Input: 1920x1080 resolution at 30fps, 40-second video, h264 (video/avc)
Output: 1920x1080 resolution at 120fps, 10-second video, h264 (video/avc)


[Dubbo-5537] remove unused variable in EtcdServiceDiscovery

What is the purpose of the change
remove unused variable  (Issue #5537 )
Brief changelog
remove unused variable from EtcdServiceDiscovery
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #5548 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #5548      +/-   ##
============================================
- Coverage     61.17%   61.17%   -0.01%
+ Complexity      423      422       -1
============================================
  Files           922      922
  Lines         37512    37511       -1
  Branches       5433     5433
============================================
- Hits          22949    22946       -3
+ Misses        12074    12072       -2
- Partials       2489     2493       +4

Impacted Files
Coverage Δ
Complexity Δ

...ache/dubbo/registry/etcd/EtcdServiceDiscovery.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ng/exchange/support/header/HeartbeatTimerTask.java
73.68% <0%> (-5.27%)
0% <0%> (ø)

...he/dubbo/common/threadpool/ThreadlessExecutor.java
55% <0%> (-5%)
0% <0%> (ø)

...pache/dubbo/remoting/transport/AbstractServer.java
53.75% <0%> (-3.75%)
0% <0%> (ø)

...he/dubbo/remoting/transport/netty/NettyServer.java
70.17% <0%> (-3.51%)
8% <0%> (-1%)

...c/main/java/org/apache/dubbo/rpc/RpcException.java
80% <0%> (-3.34%)
0% <0%> (ø)

...dubbo/remoting/exchange/support/DefaultFuture.java
75.67% <0%> (-1.81%)
0% <0%> (ø)

.../remoting/transport/netty4/NettyClientHandler.java
57.62% <0%> (-1.7%)
0% <0%> (ø)

...pache/dubbo/registry/support/AbstractRegistry.java
78.65% <0%> (-1.5%)
0% <0%> (ø)

.../dubbo/remoting/transport/netty4/NettyChannel.java
66.33% <0%> (+0.99%)
0% <0%> (ø)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

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

thanks for your contribution


llvm builds twice :(

Issue description
LLVM is built twice-- once "normally", again with manpages enabled.  IIRC the goal is to avoid spurious "rebuild world" changes on Darwin.  Unfortunately this means we build every release twice?
Perhaps the manpages build should instead be some sort of "manpages-only" build? (Not sure if that's possible...)
LLVM is a bit of a heavy dependency to build twice.
I'm not sure if both full builds (all outputs of each) are downloaded when used as a dependency in nix-shell, but that'd be unfortunate too if so :).
Steps to reproduce

Introduce change to LLVM requiring rebuild
build LLVM (nix-build -A llvm_5)
watch LLVM build twice

Technical details
(I don't believe nix-info output will be useful, but including anyway :))

system: "x86_64-linux"
host os: Linux 4.9.70, NixOS, 17.09.2430.ed3b1bc8448 (Hummingbird)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 1.12pre1234_67fe41a
channels(will): "allvm, unstable-18.03pre122666.afe9649210c"
channels(root): "nixos-17.09"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

Hmm, maybe only builds twice if you do:
nix-build -A llvmPackages_5
or mention llvm_5.man explicitly?
Hmm, sorry for noise.


add NoticeObserveKit by @marty-suzuki

Project URL

https://github.com/marty-suzuki/NoticeObserveKit
Description

NoticeObserveKit is type-safe NotificationCenter wrapper that associates notice type with info type.
Why it should be included to awesome-ios (optional)
It provides a simpler syntax for working with NotificationCenter.
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

:no_entry_sign:
Found 2 link issues

          1 Warning

:warning:
Too many changes (when adding, please keep it to one project per Pull Request)

Link issues by awesome_bot

Line
Status
Link

1039
301
https://tapglue.github.io/ redirects tohttp://www.tapglue.com/

2207
301
https://github.com/s4cha/AssetChecker redirects tohttps://github.com/freshOS/AssetChecker

  Generated by :no_entry_sign: Danger

Cool lib and nice readme!
Thanks for contributing! 👍

Cool lib and nice README!
Thanks for contributing! 👍

Thank you!


Github links added on compare page

-now github links are also fetched from api
-this links are clickable are user can visit their account

https://github.com/user-attachments/assets/b400440d-81b2-4ced-ae4c-5da9d68bcc17

@sanjay-kv please review my pr

@sanjay-kv yeah i am also searching for what else should be displayed on compare

@sanjay-kv please assign me level on this pr

sorry @17arindam i forgot to add fixed it now.


Fix the show_obs_title

Have to pass in owner_naming or else.

Looks like the main page no longer has any ill-behaved queries.  Shall I go ahead and deploy it?

Deploy away. Sorry bout this!

Easy mistake to make!  Who runs it locally and watches the log every time
they make some small tweak??
Okay... I think it's deploying okay now...  Yep.  All good now.
On Thu, Sep 7, 2023 at 2:48 PM andrew nimmo @.***>
wrote:

Deploy away. Sorry bout this!
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/1601#issuecomment-1710620695,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNLPB2QHRUV4QDBCQXDXZIJGRANCNFSM6AAAAAA4PJF4MU
.
You are receiving this because you commented.Message ID:
@.***>


Revert "Removing MLIR dependency requirement until ROCm 5.1"

This reverts commit 95b58f72f203d60e375ef4736243fe5617d73edd.
This implements step 4 of #1306.  Immediately after 5.0 release branch is cut, merge this revert PR.

Having a full pass in CI. Closing now. New PR will be filed later per #1306 tracking.


theme's seem to break when puttin the device into sleep-mode, sometimes

Before Reporting

[X] I found no existing issues matching my bug
[X] My issue is not caused by a theme

Describe the Bug
sometimes when i just turn my device back from sleep-mode, the whole theme funcionality seems to, not work, so lets say a theme has modified the workshop page for example, that whole thing, will stop working, after changing the theme, it just dosent work
Expected Behavior
it shouldnt do that, at all
Steps To Reproduce
i guess just put the device into sleep mode, it just seems to happen, im not even sure sleep-mode causes it, but so far it only happend to me whenever i had it in sleep-mode
Operating System
Windows
Anything else?
No response

Don’t worry you’re not crazy, this is a known issue planned to be fixed in the next update! I’ll keep this issue open until i’m sure it’s fixed.
Cheers!

Fixed in Millennium version > 2.0.0


Convert self supplied Assemblies to BONELAB_DIR Enviroment Variable

Generally Makes it easier/faster to compile/make pull requests to.

Honestly I don't see how anyone is going to use this other than developers making custom game modes maybe? I guess its QOL so, worth it?

the current way of creating a managed folder works fine imo

I was hating on this. But its actually really useful

ill update it to fix the merge problem

Added in c23e1b07a9e617fa19881dbbb7c55ef47fa86065 now


Support short captions (titles) appearing in list of Tables/Listings/Figures

Description
Support for long AND (optional) short captions for figures. Often, longer captions (whole sentences explaining a figure) are needed.
In LaTeX figures could have long and short captions/titles. The short one was shown in the List of Figures, the long one directly (beneath) a figure.
Use Case
Table of Contents, List of Figures, List of Tables, List of Listings would look much better.

Duplicate of https://github.com/typst/typst/issues/1295


feat: accept strings that evaluates to bool in release condition

This adds more flexibility to helmfile conditioning by:

Adding: strconv.ParseBool() allows evaluating strings to booleans which gives possibility to extend the conditioning functionality
Changing: the error message displayed on the terminal when value for the condition field is neither in 'foo.enabled' format nor a string that can be evaluated to bool value
Removing: -

Resolves: https://github.com/helmfile/helmfile/discussions/837
With this PR the following configuration:
environments:
  # by default there are no deployments enabled
  default:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: false
      - bar:
           enabled: false
  # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true
  # One release at time starts here
  foo:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: false
      - bar:
           enabled: false
  boo:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: true
      - bar:
           enabled: false
  bar:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: false
      - bar:
           enabled: true

can be minimized to:
environments:
  # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true
  # One release at time starts here
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values:
      - bar:
           enabled: true

and then in the helmfile.yaml this can be specified:
releases:
  - name: foo
    chart: ./foo
    condition: '{{ .Values | get "foo.enabled" "false" }}'
  - name: boo
    chart: ./boo
    condition: '{{ .Values | get "boo.enabled" "false" }}'
  - name: bar
    chart: ./bar
    condition: '{{ .Values | get "foo.enabled" "false" }}'

and the following commands will work just fine:
# apply foo only
helmfile -e foo apply

# apply boo only
helmfile -e boo apply

# apply bar only
helmfile -e bar apply

# apply everything
helmfile -e all apply

What are cons here?
Users will have to chose the way of defining the conditions and stick to it. The 'string to bool' (the one proposed in this PR) and 'variable path to bool' (the one that is currently in use) approaches cannot be mixed. Mixing of these two approaches will result in panic:
panic: environment values does not contain field 'sampleFieldName'

Hope you will find this useful and accept this PR! 😄
P.S. I did not add the docs yet, as I do not know if you will accept this PR. If there will be a green light, then I'm more than happy to update the documentation.

Why not use installed field?

Hey @PatrykKlimowicz! Thanks for your contribution.
I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

The every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?
Sorry if I lost memory or missed something. Thanks in advance for your help!

Why not use installed field?

Correct me if I'm wrong, but releases marked with installed: false will be uninstalled in the next sync. With this proposal this won't be the case.

Hey @PatrykKlimowicz! Thanks for your contribution. I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

Every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?
Sorry if I lost memory or missed something. Thanks in advance for your help!

Sorry, I do not have the possiblity to provide the full description here. I will update later today/tomorrow morning with the examples.

Hey @PatrykKlimowicz! Thanks for your contribution. I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

Every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?
Sorry if I lost memory or missed something. Thanks in advance for your help!

 Right now there is a need to specify the envs as following:
environments:
  foo:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: false
      - bar:
           enabled: false
  boo:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: true
      - bar:
           enabled: false
  bar:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: false
      - bar:
           enabled: true

and this is because of how condition has to be specified. Helmfile is forcing the approach of foo.enabled, hence we have to repeat the values to make the following works:
releases:
  - name: foo
    chart: ./foo
    condition: 'foo.enabled'
    values:
      - ./foo/values-extra.yaml

  - name: boo
    chart: ./boo
    condition: 'boo.enabled'
    values:
      - ./boo/values-extra.yaml

  - name: bar
    chart: ./bar
    condition: 'bar.enabled'
    values:
      - ./bar/values-extra.yaml

so if we ran the helmfile -e foo diff the conditions for boo and bar releases will be evaluated, it will turn out that value is false, so only foo will be enabled. But all used values in condition field must be defined for given environment.
This PR gives us possibility to minimize the code duplication in the environments section thanks to the use of get template function that provides us opportunity to specify the fallback value. We can do the following:
environments:
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values
      - bar:
           enabled: true

However, to avoid panic in the ConditionEnabled function we have to change the way of defining the value in condition field. What we are looking for is the actual value of this foo.enabled var passed in example above. To be precise, string that can be converted to boolean. Now, the releases will look as following:
---
releases:
  - name: foo
    chart: ./foo
    condition: '{{ .Values | get "foo.enabled" "false" }}' # obtain value or fallback
    values:
      - ./foo/values-extra.yaml

  - name: boo
    chart: ./boo
    condition: '{{ .Values | get "boo.enabled" "false" }}' # obtain value or fallback
    values:
      - ./boo/values-extra.yaml

  - name: bar
    chart: ./bar
    condition: '{{ .Values | get "bar.enabled" "false" }}' # obtain value or fallback
    values:
      - ./bar/values-extra.yaml

After we ran the helmfile -e foo apply command, get function will try to obtain the values for foo.enabled, boo.enabled, bar.enabled vars, but we know that only foo.enabled is defined, hence for other two the fallback value false will be used as the entry for condition field. Since it is a string that we can convert to bool, both boo and bar releases won't be applied.
In the current approach of helmfile, we have to specify the default values in the each environment. This PR does not impact the helmfiles that people has created already. It also does not change the default helmfile behavior. It adds possibility to use the "special" strings as the value for condition field and thanks to the usage of get template function we can specify defaults in inline manner.
Why this is important to have this possibility?
Current helmfile # releases / # loc in whole environments section:

2/12 - 6 lines per release
3/24 - 8 lines per release
4/40 - 10 lines per release
5/60 - 12 lines per release
6/84 - 14 lines per release

With this PR we can achieve # releases / # loc in whole environments section:

2/8 - 4 lines per release
3/12 - 4 lines per release
4/16 - 4 lines per release
5/20 - 4 lines per release

Happy to answer some more questions 😄

To give you some insights how exactly the code change is working:

If condition is not defined or is "" return true, nil immediately
If condition is string that is convertible to boolean, return it's bool representation
Check if passed string which is referencing variable follows the convention of 'foo.enabled'
Process given var, and return true/false

@PatrykKlimowicz Thanks for clarifying! Ah gotcha! So the key idea in this pull request is that you define default values in get template function calls, whereas "ideally," the default and override values are defined under environments... correct?
Presuming that's correct, how about implementing some kind of "inheritance" to environments like we've done for templates/releases in https://github.com/helmfile/helmfile/pull/606?
It could be implemented to look like this:
environments:
    # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true
  # One release at time starts here
  foo:
    inherit:
      environment: all
    values:
      - foo:
           enabled: true
  boo:
    inherit:
      environment: all
    values:
      - boo:
           enabled: true
  bar:
    inherit:
      environment: all
    values:
      - bar:
           enabled: true

or to avoid mixing "template" environments (like "all", which is not supposed to be used directly via -e all) and regular environments-
environmentTemplates:
    # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true

environments:
  # One release at time starts here
  foo:
    inherit:
      template: all
    values:
      - foo:
           enabled: true
  boo:
    inherit:
      template: all
    values:
      - boo:
           enabled: true
  bar:
    inherit:
      template: all
    values:
      - bar:
           enabled: true

or more simply, introduce some defaults like helmDefaults for `releases[]-
environmentDefaults:
  # one env to rule them all
  values:
  - foo:
       enabled: true
  - boo:
       enabled: true
  - bar:
       enabled: true

environments:
  # One release at time starts here
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values:
      - bar:
           enabled: true

The key idea is to make the hardcoded nature of condition field more flexible. As a result this is possible:

define default values in get template function calls

The proposals you've made are kind of interesting! I'd say environmentDefaults is more elegant way of what I made with get template function.
I really like the clean nature of inherit approach. Since it has been already implemented in the other places I believe it's good idea to "extend" this keyword on the environments section as well. I can work on this proposal - no problem 😄
Anyway, the idea from this PR can be independent from the inherit approach. Is there any strong reason that condition can only be foo.enabled and not true or false explicitly? And why only two levels of nesting are valid? Why we cannot use variable like foo.release.enabled? The hardcoded nature of this field is really strange. As you can see, the possiblity to pass to condition strings that can be evaluated to bool is pretty powerful and is achievable with small amount of changes in the code.
To sum up, it would be really nice to have this inherit functionality with environments section (I can create PR for that) AND it would be nice to make the condition field more flexible. WDYT?

@mumoshu any decisions? 😄

Is there any strong reason that condition can only be foo.enabled and not true or false explicitly?

Yes! That is to make the condition field look very similar to helm's Chart.yaml condition field, with takes a path in values.yaml.

Is there any strong reason that condition can only be foo.enabled and not true or false explicitly?

Yes! That is to make the condition field look very similar to helm's Chart.yaml condition field, with takes a path in values.yaml.

Ok, I'll propose this inherit + environmentsTemplate functionality in the new PR then 😄

@PatrykKlimowicz any updates?

I don't understand the benefit of this PR ?
don't quote around the go-template and it will work already:
    condition: {{ .Values | get "foo.enabled" false }}

@PatrykKlimowicz any updates?

Sorry, got stuck with other work. I'll open PR tomorrow

I suggest to extend it not only for bools, but also for other types - see my topic in discussions: https://github.com/helmfile/helmfile/discussions/926

@JuryA Hey! Please also see this one https://github.com/helmfile/helmfile/issues/913#issuecomment-1643395196 In short, I'm thinking if we are about to outgrow yaml + go template based solution....

@JuryA Hey! Please also see this one #913 (comment) In short, I'm doubting that we are about to outgrow yaml + go template based solution...

Greetings. Apologies for the delayed response. I've taken some time to evaluate the benefits of both Jsonnet and CUE. Both have their unique advantages and optimally, supporting both would be beneficial. However, I understand this might complicate the codebase.
The immediate issue to address is the unavailability of some key fundamental information. Currently, obtaining this data requires cumbersome, less-than-ideal methods. This problem is magnified when considering cross-platform compatibility, affecting Windows, Linux, and macOS. Fortunately, one can rely on Git for this purpose. For example, on Windows, we can use:
git -c 'alias.cmd=!<some command> <its_args>' cmd

It's a somewhat inelegant and hacky solution, isn't it? 😬 But it ensures that the command will execute in Git Bash on Windows and in a suitable shell on other POSIX platforms.
It would be advantageous to directly provide some well-known information at runtime by Helmfile itself among other objects.
For example:
Helmfile Root Directory:
values:
  - Helmfile:
      Paths:
        helmfileRoot: !!str {{ exec "git" (list "-c" "alias.pwd=!pwd" pwd) | trim | osClean }}

PWD:
{{ $PWD := env "PWD" | osClean }}

Pertinent Paths:
{{ $Helmfile := .Values | get "Helmfile" (dict) }}
{{ $Self := $Helmfile | get "Self" (dict) }}
{{ $helmfilePath := $Self | getOrNil "helmfilePath" }}
{{ $helmfileDir := $helmfilePath | osDir }}
{{ if not $helmfilePath }}
  {{ print "\n\n.Values.Helmfile.Self.helmfilePath not defined!\n\n" | fail }}
{{ end }}

Other Paths:
  - Helmfile:
      Self:
        helmfileDir: &helmfileDir {{ $helmfileDir | osClean | quote }}
        helmfilePath: &helmfilePath {{ $helmfilePath | osClean | quote }}
        helmfileName: {{ $helmfilePath | osBase | quote }}
      Paths:
        helmfileDir: *helmfileDir
        helmfilePath: *helmfilePath

... and many others...


Cannot Connect To Unverified SSL

When trying to connect to https://example.com I get:
System.err: javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
The last log then comes from the JsonHttpResponseHandler:
response body is null, calling onFailure(Throwable, JSONObject)
any solution?

AsyncHttpClient client = new AsyncHttpClient(true, 80, 443);
work with me thanks

This is a huge security issue ...


VS Code Azure Functions extensions warns to update to Core Tools 2.0.1-beta.37 even though the Ubuntu 18.04 PPA has no such version

The Azure Functions extension for VS Code warns:

Update your Azure Functions Core Tools (2.0.1-beta.35) to the latest (2.0.1-beta.37) for the best experience. v2 is in preview and may have breaking changes (which are automatically applied to Azure).

However, there is no such version in the Ubuntu 18.04 PPA (yet), the latest version published is still 2.0.1-beta.35.

We check npm to see what the latest version is since npm is the only install method that's available on all OS's. You're welcome to install with npm if you want to be on the latest or turn the warning off with "Don't warn again".
The only fix I can see is to check every different install method and base the warning on that, but I'm not sure that's worth investing in. Ideally the functions cli releases every option with a few days of each other anyway
You're welcome to contribute a fix. Otherwise any objection to me closing this as won't-fix?


Some question about DRMM_TKS

whether exixt the paper that detailed introduce the DRMM_TKS ?

In fact, this method incorporated ideas from DRMM and PACRR (2017 A Position-Aware Deep Model for Relevance Matching in Information Retrieval), it has not been published.

@WelcomeLi I'll close this issue for now, hope your question has been solved, best!


How to use columns which may be NULL?

Hi, thanks for writing this library!
I don't understand how I can create a column that may be NULL in the database. Take a struct like the following:
type Person struct {
   ID int64
   BossID sql.NullInt64
}

When a database is created by modl, the type of the column BossID (at least for sqlite3) is text. Why is that?
I have found the code mapping a column to the type here: https://github.com/jmoiron/modl/blob/master/dialect.go#L111-L112 It seems that it does test for the type name NullableInt64 instead of NullInt64. Is that intentional or a bug? I was unable to find any reference to the string NullableInt64, except in an early discussion on how to name the types within sql.Null*.
Creating a custom type works, but I don't think that this is the way it is supposed to be:
type NullableInt64 sql.NullInt64

Now a database column with the type integer is created.
Am I missing something?

For gorp, which modl is a fork of, this was changed in 30f5a47e7a7fb0e0f9b616502e0f316c66cdee70 https://github.com/go-gorp/gorp/pull/121


Add list & comment arguments enables usage with other regex lists

This pull request adds the following subcommands to the install script.

--list [string] (regex.list of choice)
--comment [string] (Comment of choice)

If you choice none of these subcommands the default is used.
Usage
curl -sSl https://raw.githubusercontent.com/nickspaargaren/pihole-regex/args/install.py | sudo python3 /dev/stdin --list https://raw.githubusercontent.com/nickspaargaren/no-google/master/regex.list --comment github.com/nickspaargaren/no-google

TODO

[ ] Update uninstall script as well
[ ] Update readme with fictive/general list and command

Closes https://github.com/mmotti/pihole-regex/issues/61

Great addition!

Hi! Apologies for the delay in response; I haven't had Pi-hole installed for some time.
Unfortunately the diff for this particular change isn't too helpful for me to be able to look through this quickly and I'd have to familiarise myself once again with the code.
Are you able to confirm that this has been tested and works as expected?

I was merely trying to apply multiple lists and noticed that when you apply a list all previous entries will be deleted/disabled. Adding command line arguments to select which allow/block lists one wants to apply would be a great addition.

Hi @mmotti! My apologies for leaving this PR open for so long. I've added a "How to test" section so you can verify the changes using a new Pi-hole installation with Docker. Let me know if you need anything!


Feature Request: please add onError hook

Please refer to this StackOverflow post for more details: https://stackoverflow.com/questions/65989260/karate-how-to-configure-the-afterscenario-hook-in-a-called-feature
It'd be great to have an onError hook available for use in called features. Given the example from the above post, I'm assuming the test2.feature file would look something like this?
Feature:

Background:
    * print 'this is a background 2'
    * def testId = 222
    * configure onError = function(){ karate.write({ id: testId, errorMessage: karate.info.errorMessage }, 'test-id-' + testId + '.json'); }

Scenario: test2
    * print 'this is test2'
    * karate.write({ id: testId, errorMessage: null }, 'test-id-' + testId + '.json')

Thanks in advance for looking into this!

@treboriwa to be honest this is adding complexity to karate I'm not comfortable with.
@joelpramos your thoughts ? can the new configure be of use in this case

Wasn't how I intended to use but maybe the following will work (pseudo code using the keyword introduced on https://github.com/intuit/karate/issues/1446):
    * def someJsonArray = []
    * configure continueOnStepFailure = { enabled: true, continueAfter: true, keywords: ['call'] }
    # have your test3.feature write in some json array
    * call read('test2.feature')
    # have your test3.feature write in some json array
    * call read('test3.feature')
    * configure continueOnStepFailure = { enabled: false }
    * karate.write( .... etc)

The way you should read the above is that basically after the configure keyword your scenario will continue executing even if steps with the keyword 'call' fail. The parameter continueAfter will ensure that the execution of the scenario will continue even after you disable this configure. I added the "disable" before the karate.write() cause I think I didn't account for the usage of karate.write() directly.

@joelpramos I'm inclined to close this as wontfix but exploring this further:

I am not in favor of having afterScenario and afterFeature work for "called" features
because this means we have to specify "which level" the hook applies to, keep in mind these can be "configured" any time, even in the "global" karate-config.js
hypothetically speaking, if we decide to intro an onError hook, and we decide that this is "global" and activates even for "called" code
now if continueOnStepFailure is enabled, how will this work ? can get confusing, so that's another reason I don't like this

@joelpramos @ptrthomas Thank you for looking into it!
If I'm reading your above snippet correctly, it would get us closer to satisfying the use case I brought up, but still wouldn't capture the test result of "called" features (test2.feature, test3.feature). continueOnStepFailure would only ensure the "top level" feature executes the block where enabled is set to true.
But I'm just wondering... I really like the Karate feature of being able to pass variables to "called" features e.g. * call read('login.feature') { username: 'admin', password: 'secret' } What if you expanded on that and enabled passing hooks to "called" features? So you could do something like * call read('login.feature') { username: 'admin', password: 'secret', afterScenario: true }

What if you expanded on that and enabled passing hooks to "called" features

good point. actually the design is such that this below has the same effect. the principle is that any variable is "visible" to called features (and those called by those)
* def afterScenario = true
* call read('login.feature') { username: 'admin', password: 'secret' }

@treboriwa can you take a step back and summarize what you want to achieve at a high level, maybe there are other ways in karate to achieve what you want. I am still open to a "global" onError - actually we have it internal now, and it takes a screenshot of the page if it is a UI test. I think you would be able to make a call to metadata (e.g. karate.scenario | karate.feature) and get the call "depth: and feature name to make decisions
one thing that struck me @joelpramos is there a way to check if we have collected an error when in continueOnStepFailure mode, I'm sure this use-case above may need that (another reason this is adding too much complexity for my comfort)

@ptrthomas In a nutshell, I need to capture the result of the "called" feature and write it to a JSON file for post execution processing. The after hook seems like the most effective way to achieve that, if it was possible to trigger it for "called" features.
So, if I have a "top level" feature (test1.feature) which calls two other features (test2.feature and test3.feature) each of which has an afterScenario hook in it to write a JSON file with test results, only the result of test3.feature will get captured and written to a JSON file, since its Background will be the last one to get loaded. Unless test2.feature fails, then that result will get captured and the call to test3.feature will get skipped.
Please let me know if you'd like me to provide more details.

@treboriwa how about this:
* def results = []
* call read('one.feature')
* call read('two.feature')
* karate.write(results, 'results.json')

one.feature
* def temp = { message: 'from one' }
* karate.appendTo(results, temp)

did I miss anything ?

@joelpramos I'm inclined to close this as wontfix but exploring this further:

I am not in favor of having afterScenario and afterFeature work for "called" features
because this means we have to specify "which level" the hook applies to, keep in mind these can be "configured" any time, even in the "global" karate-config.js
hypothetically speaking, if we decide to intro an onError hook, and we decide that this is "global" and activates even for "called" code
now if continueOnStepFailure is enabled, how will this work ? can get confusing, so that's another reason I don't like this

I thought that afterScenario() / afterFeature() using the ExecutionHook is already called at all times? I was referring to using the Hook interface if it wasn't clear.
continueOnStepFailure shouldn't change anything in the hooks. There's already an afterStep() that should get invoked regardless of the step being successful, failed, skipped, aborted. Again, up to the implementer of the ExecutionHook to code special behaviors if they are intending on having special use cases.
@ptrthomas your example above won't work if 'one.feature' fails which is why OP needs continueOnStepFailure, which will continue the execution (although depending on the complexity maybe the karate.write() can just move to the afterScenario configured via the Karate DSL).
Something that might be beneficial (and maybe already exists) for this use case would be for the karate api to give access to the runtime objects or keep a reference whether there's an error in the scenario or feature. Picking up the sample from @treboriwa something like the below:
    * configure afterScenario = function(){ if (scenario.isError()) { karate.write({ id: testId, errorMessage: karate.info.errorMessage }, 'test-id-' + testId + '.json'); } }

using the ExecutionHook is already called at all times? I was referring to using the Hook interface if it wasn't clear.

yes you mean RuntimeHook. OP is referring to configure afterScenario = fun. `that hook is limited by design as I said to only fire when callDepth == 0

@ptrthomas your example above won't work if 'one.feature' fails
fine. then use the Java RuntimeHook. I'm declaring this a wontfix because my brain can't handle all the cases. you both can decide if you want to make all of this work via a karate.blah() API, I'm going to pass for now

closing but PR-s can be submitted using this issue ref

just remembered a hack that may elegantly solve the requirement here. you can wrap anything in karate in JS try-catch blocks and handle errors manually. and you can wrap this into some reusable function etc.
* eval
"""
try {
  karate.call('some.feature');
} catch (e) {
  karate.logger.error('failed:', e);
  // do your custom cleanup or logging
  karate.fail('failed because of: ' + e);
}
"""


WIP — Feature/question page

Mostly test setup so far!
STILL TO DO

~finish e2e test for question page~
~rebase and rewrite commits~
add package.json & integrate govuk-frontend  < will do this in next PR

Now working with pg in actions


fix: update query expression type of column parameters

[ ] Added or updated tests
[ ] Documented user facing changes

Changes

Updated the type hints for query expression parameters, handling a change in Laravel 10.
Breaking changes

I just noticed this is already being discussed in #1547. Closing this pull request for now.


Use Existing RF scanned codes ?

I setup my RM Pro to test a handful of RF ceiling fans and outlets prior to setting up the Homebridge and RM plugin. It was an extensive procedure since I had to cycle through multiple button presses due to the nature of my devices.
Is it possible for the plugin to recognize or retrieve the already stored RF codes so that i can add them into my accessory list?

Not a bad idea, I'll look into it.

Had a quick look into this today, found 2 possible ways to do this.

The app has a cloud backup feature, I found the endpoints but in the limited amount of time I spent on this was not able to authenticate to get a backup
The app has a WLAN share feature, enabling this will broadcast on the network a endpoint that once accessed gives out a zip archive with all of the app configuration.

This is a example of a RF button from my RM PRO+ for a light switch:
{     "code": [       -78,       69,       38,       0,       6,       6,       6,       6,       10,       6,       6,       6,       5,       7,       5,       11,       6,       6,       6,       6,       5,       6,       17,       6,       5,       6,       6,       11,       6,       5,       11,       11,       11,       6,       5,       6,       5,       7,       5,       11,       11,       11,       0,       0     ],     "id": 1,     "order": 0,     "delay": 0,     "buttonId": 1,     "name": ""   }
Maybe someone else has a better understanding of the codes and can easily convert that into a hex

Also, if anyone can figure out the format of this file it would be awesome
I have an air conditioner (Beko) added in the app. The remote was recognised by the app as a "rn02j" and the attached file looks like the configuration for it.
The shared archived contained this file under "ConCode" directory
1037.gz

Great work thanks @70mmy. I doubt that the cloud sync is encrypted beyond SSL so with the correct authentication we should be good to go with that.
Have you any devices other than an AC? They often have the current time included and so the code changes each time. If you had another device you could learn that in the plugin and compare it to the array from the second method.

The JSON fragment above is for a RF switch, the hex code learned with the plugin for the same device is:
b280260011060506050b06060b0b0b0605060506050b0b0b060506050b0606060606050b0606060605060000
The cloud uses a MD5 signature approach to secure requests, the signature is a JSON representation of the request, salted with a static key (that I found) but I was not able to do a valid request, and since there was an easier method I chose not to waste any more time.
If the information in there is useful and we can actually get it to work, we can invest more time into getting the info from the cloud

Awesome information thanks @70mmy, I'm impressed they went to the effort. When I get my new RM Pro on Wednesday I'll spend a little bit of time on the cloud function and then revert to the second if I have no luck.

I downloaded the android APK and decoded it with an online tool and poked around the source code to get a feel of how they did it, you can find the endpoints in there and salts for different actions, I can give you some details if you'd like, so you don't start from scratch.
On the other hand, I think the second method is actually better because you don't need to create an account with them for it to work.

I managed to get the plugin to work (switch my light on and off) with a hex generated from the decimals array in the shared archive by the app.
The way I see this would work at this point is to:

Add a new import button similar to the ones for learning IR or RF
When pressed, the code will listen for UDP broadcast and download the shared archive
Extract from the archive the configured buttons each with it's own hex code available
Print the buttons in the log

As for the AC, the file above should be the configuration for my AC, I can successfully control the AC from the app using that config.
At this point I suspect the file is a password protected sqlite database, but did not have time to research it further

I did the import using the share method:
https://github.com/lprhodes/homebridge-broadlink-rm/pull/533
It logs something like this:
Import listener started, go to the app and click on 'Share to other phones in WLAN'
Download from: http://Andreis-iPhone.local:48815
Extract archive: /tmp/BLImport/shared.zip
Extract codes from: /tmp/BLImport
Codes: [ { name: 'Living high',
    hex: 'b2452606666a666575b666656116566b65bbb656575bbb00' } ]

I'm not really a node js developer, so any suggestion you might have on the code are welcomed

Thanks, my new RM Pro gets here Wednesday so I’ll check it out then.

On 11 Jan 2020, at 10:29 pm, 70mmy<EMAIL_ADDRESS>wrote:

I did the import using the share method:
#533
It logs something like this:
Import listener started, go to the app and click on 'Share to other phones in WLAN'
Download from: http://Andreis-iPhone.local:48815
Extract archive: /tmp/BLImport/shared.zip
Extract codes from: /tmp/BLImport
Codes: [ { name: 'Living high',
hex: 'b2452606666a666575b666656116566b65bbb656575bbb00' } ]
I'm not really a node js developer, so any suggestion you might have on the code are welcomed
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Just discovered there are 2 more apps working with the RM, the code I made is for the "e-control" but there is one called "Broadlink" and another called "IHC"

@70mmy Yes, it's quite confusing!
And to make it worse, the e-Control app seems to no longer work with the most recent version(s) of RM2Pro bought in the last few months, which is what I have - this seems to require either the "IHC" app, or another app called "IHC EU". This has a type id of 279d which is different from earllier RM2's.
Unfortunately I haven't managed to find a way to capture RF codes successfully from these. It can be detected and identified by the windows "Broadlink Manager"  ("RM2Pro3") but I've not managed to get it to capture RF codes. Similar with python-broadlink. I wonder if Broadlink have somehow changed the protocol slightly?
@lprhodes lprhodes: very interested to hear what you find with your new RMPro when it arrives!!

Me too, I have Wednesday evening free to test and make sure we can all scan RF codes consistently and easily (and import them!)

On 13 Jan 2020, at 8:45 pm, Andrew<EMAIL_ADDRESS>wrote:

@70mmy Yes, it's quite confusing!
And to make it worse, the e-Control app seems to no longer work with the most recent version(s) of RM2Pro bought in the last few months, which is what I have - this seems to require either the "IHC" app, or another app called "IHC EU". This has a type id of 279d which is different from earllier RM2's.
Unfortunately I haven't managed to find a way to capture RF codes successfully from these. It can be detected and identified by the windows "Broadlink Manager" ("RM2Pro3") but I've not managed to get it to capture RF codes. Similar with python-broadlink. I wonder if Broadlink have somehow changed the protocol slightly?
@lprhodes lprhodes: very interested to hear what you find with your new RMPro when it arrives!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


enabling passing pymc step function reference in sampler_config

Addressing issue reported by @ColtAllen  in #319. Because of context requirement the step function should be passed as a reference in the sampler_config.

:books: Documentation preview :books:: https://pymc-marketing--320.org.readthedocs.build/en/320/

passing function reference causes problems with json serialization, as ABCMeta objects (which the pymc step function objects inherit from) aren't JSON-serializable, therefore we need to proceed with the same way as we did with priors. So the 'step' needs to contain string representation of the desired pymc step function:
instead of passing pm.Slice() -> 'Slice'

instead of passing pm.Slice() -> 'Slice'

Why do the sampler args need to be serializable?

Maybe it makes sense to subclass fit in the pareto model to allow fit_method="mcmc_slice"? I don't think we need to worry about custom step samplers in other models.

The main point of model builder is the ability to completely reproduce the model, without previous knowledge about it (let's assume some devops deploying a model to AWS EC2) In that case he shouldn't be forced to know which step method should be applied on the fit step, especially if originally the models developer included it in the sampler_config, which is meant to be preserved.

We're not, because it's not part of neither model nor sampler config. We're saving only idata, which attrs contain model_config, sampler_config and input parameters in case of MMM models (the CLV models don't have any input params outside of dataset, which is saved within the idata). This and model version + id

If you're not saving fit_method="mcmc" vs fit_method="map", I don't see how that's different to also not save fit_method="mcmc_slice"? Your argument against "mcmc_slice" would also apply to "map"

I'm getting confused now, you @'ed me under issue reporting this, and when I asked if it's something that we'd like to have everywhere you didn't object. For the future reference if it's not something that we want to address on a global level let's state it directly in the issue, so I know that I shouldn't spend time for investigation and implementation.
We could add another handler for covering the mcmc/MAP choice and keep it managed completely through the sampler_config, or just abandon the idea, but seeing it now actually it looks like something I'd like to have on the model_builder level, then it's up to users to either keep it when they re-implement the fit() function to match their project needs

If the idea of ModelBuilder is that the sampler settings are also saved/loaded then I agree it makes sense in the base class.


Using a FAB for submitting?

When editing a long case/method/org, the page can be very long.  Which means that hitting submit requires scrolling way down to the bottom of the page.
How about we use a FAB floating action button like we do for the edit button to do the submit, maybe using the send icon:
 inside of the usual red circle?
@samjiangweb

I implemented this because it was painful for me.  Happy to rip it out if we have a better answer.


Validation of translation placeholders for localized (de) failed

Checklist

[X] I have updated to the latest available Proxmox VE Custom Integration version, see the latest version here.

Describe the issue you are experiencing
When I restart Home Assistant I get the following error:
Logger: homeassistant.helpers.translation
Source: helpers/translation.py:288
First occurred: 12:48:13 (1 occurrences)
Last logged: 12:48:13

Validation of translation placeholders for localized (de) string component.proxmoxve.issues.resource_nonexistent.description failed

So far everything seems to be working without any problems.
In which version of Home Assistant Core do you have the problem?
2024.2.2
What version of Proxmox VE Custom Integration has the issue?
3.4.0
What version of Proxmox VE do you have the problem?
8.1.4
Diagnostics information
No response
Additional information
No response

@nima-1102 and @ancientm74
Possibly they were resolved in #269 and #270. Can you test the main version (install the main version through HACS) to verify?
Ideally, natives like you should review the translations to correct them, see an example in #269 and #270.
The solution is up to me to remove the translations that have a reserved space from the languages that are presenting problems, new translations would depend on native speakers performing the translations.

I just found that I had the same error. Switched to main, as you suggested @dougiteixeira. Can confirm this fixes it. Thanks!

@dougiteixeira
Sorry for the late reply, the problem is now solved. The German translation looks good, thank you very much.


How to keep edit mode open if server returns 400

How to keep open edit mode if server response with error? Now, when I click submit and send data to API, my form automatically is close, but I want to close edit mode only if server response with success, and stay opened if a response with an error. Thank you
`
$scope.saveTableConfig = function () {
var config = {
headers: {
'Content-Type': 'application/xml',
'X-HTTP-Method-Override': 'PUT'
}
};
    var configCopy = angular.copy($scope.currentConfig);

    $http.post(serviceBase + 'cd/saa/' + $stateParams.aaaID + '/config', configCopy, config)
            .success(function (data, status, headers, config) {
                Notification.success({message: $filter('translate')('BENCH_EDITED_SUCCESSFULLY'), delay: 3000, positionY: 'bottom', positionX: 'right'});
            })
            .error(function (data, status, header, config) {
                Notification.error({message: $filter('translate')('BENCH_EDITED_ERROR'), positionY: 'bottom', positionX: 'right'});
            });

};

form editable-form name="tableform" onaftersave="saveTableConfig()" oncancel="cancel()">
Text
</form`
I ask on stackowerflow, but there is no any reply.

You need to return a string value in your onaftersave method:
`If you need to send data on server after writing to local model then you should define form's onaftersave.
The result of form's onaftersave is also important for next step:
string: form will not close (e.g. server error)
not string: form will be closed`

Thank you for your reply. Please could you give me a little more detail to explain this, because I did not quite understand

I fix this, thanks to @ckosloski


Update Roslyn version to 2.9.0, require exact in NuGet

Directory.Build.props gained RoslynNugetVersion with 2.* 2.9.0 value to always depend on latest Roslyn.
CodeGeneration.Roslyn has strict dependency on this version: Version="[$(RoslynNugetVersion)]"
Closes #77

I've been misled by MSBuild/deps.json cache to believe it could work with floating version - it cannot. I've since fixed my error, and made the RoslynNugetVersion be exact, currently 2.9.0.

@AArnott pinging for comment/review

Thanks.


Missing resources based on provider version 1.11.1

In the new version I'm missing a lot of resources like creating tunnel interfaces, ipsec and ike config.
Will this be added in future releases?
And based on the new routing engine "Advanced Routing", is this logical router something that can be expected in some future releases?
Additional context
I tried to rebuild my terraform script to create a site to site vpn with the Advanced routing engine enabled. I saw the new version but couldn't find the resources.
I tried the script with version 1.11.1 and saw Panorama was abled to process the virtual router config, and pushed this to the logical router on the firewall.
But it should in panorama also be present in te logical router config of course.

It's the default version on the terraform docs page: https://registry.terraform.io/providers/PaloAltoNetworks/panos/latest/docs
Not ideal to have an alpha version that isn't recommended to show as the default


Custom coordinate systems

May I ask if MapTiler SDK JS supports loading Vector Tile Layers with custom projections?Thanks！

Hello @gisxuh , no unfortunately the SDK does not support any custom projections at the moment.


Decreasing Speed and Delayed Confirmation in Stream Transcription Over Time

I’ve been using WhisperKit for real-time stream transcription in a project, and I’ve noticed that as time progresses, particularly after 20-30 minutes of continuous use, the transcription speed begins to decrease noticeably. Additionally, the transcript seems to remain unconfirmed for an extended period. During this time, the same text is repeated for a long duration within the unconfirmed segment, which results in the latest transcript not being transferred in a timely manner. This causes a significant gap between the audio and the corresponding transcription.
I’m aware that this issue might be challenging to resolve quickly, but I’m curious about the potential causes. Could this be related to Model-Level Issues, Decoder-Level Issues or others?
I would appreciate any insights into which areas might be the most likely cause of the issue. If there are specific parts of the code or certain tools I should use to investigate these potential causes further, I’d be grateful for the guidance.
Thanks

@gavin1818  Thanks for the report! Are you able to share the input file that reproduces this?

@gavin1818 Could you also provide a little info on the model, device, an os you're running on? There could be a number of different potential issues depending on that.

The realtime demo seems to be running Whisper over the full recorded file, and using seeking to transcribe the most recent bit.
Would that be slowing things down? Would it make sense to cut it off - accepting that we would lose some of the context?

For realtime it is looking for a specific amount of confirmations to say that it effectively transcribed some set of audio without any cutoff in the middle of words. That is set to 2 segments currently which does end up being slower because we need to fix the timestamp filter to get smaller segments. You can configure it to only use 1 segment confirmation which might help. We also have a task to drop audio after transcribe is completed, but that wouldn't impact performance.

For realtime it is looking for a specific amount of confirmations to say that it effectively transcribed some set of audio without any cutoff in the middle of words. That is set to 2 segments currently which does end up being slower because we need to fix the timestamp filter to get smaller segments. You can configure it to only use 1 segment confirmation which might help. We also have a task to drop audio after transcribe is completed, but that wouldn't impact performance.

Do you mean that the current word-level timestamp might be inaccurate? Because if it were accurate, then cutting the buffer based on the end time of a word shouldn’t result in splitting a word in the middle, right?

Word-level timestamps have to be accurate for realtime (eager) mode to work, but cutting the buffer changes the start time of the audio, and since we are using seeking (aka clipTimestamps) to decode the next segment of real time audio as it comes in from the microphone, the seek value would also have to be reset if we're dropping audio from the buffer, in order for the clipTimestamps to correctly seek to the point in the buffer that has yet to be transcribed. None of that is super complicated to build into the system, so we're keeping all these kinds of things in mind for when we take eager mode out of the experimental stage.

Word-level timestamps have to be accurate for realtime (eager) mode to work, but cutting the buffer changes the start time of the audio, and since we are using seeking (aka clipTimestamps) to decode the next segment of real time audio as it comes in from the microphone, the seek value would also have to be reset if we're dropping audio from the buffer, in order for the clipTimestamps to correctly seek to the point in the buffer that has yet to be transcribed. None of that is super complicated to build into the system, so we're keeping all these kinds of things in mind for when we take eager mode out of the experimental stage.

Thank you for your reply


Support other url protocols or patterns for clickable links

Description of the new feature/enhancement
I would like to be able to have clickable links for gopher or gemini links, maybe also for xmpp links in the terminal text

Proposed technical implementation details (optional)
The pattern what links are clickable currently matches http and https links and is hardcoded into the code, it would be better if this were settable in the json file so that one can define other url patterns to be matched.


Fixed text2speech API problem

The text2speech use case now works for both windows & Mac
Remember to switch the API key to your own file path when calling the API

Greatly improved the cross-platform usability, ensuring users on different OS can now utilize the functionality.
I appreciate for reminder about switching the API key


feature: send found patches to Twitter

Automate send of information to Twitter or Slack.

@monperrus I can sketch a PR on this. Please let me know.

Excellent! Welcome!

@monperrus great would be working on this 👍


How to combine an array of Observables

Hi there
I am trying to combine an array of Observables and bind it to a single Observable. The number of Observables is not know at compile time.
`
let isDataValid = Observable(false)
var questionViews:[KnowledgeQuestionView]! {
    didSet {
        var observables = [Observable<Bool>]()

        for questionView in questionViews {
            observables.append(questionView.isDataValid)
        }

        combineLatest(observables, combine: {elements -> Bool in
            /*
             iterate over elements and if any are false 'return false'
             */

            return true
        }).bind(to: isDataValid)
    }
}

`
The issue i am having is that the combineLatest method which takes an array only takes an array of Signals, not SignalProtocol elements, therefore the code above fails to combine as it can't convert Property<Bool> to Signal<_,_>
Is there any way to achieve what i want using ReactiveKit?
Many thanks
Chris

Unfortunately there is no such operator at this time.

Not sure if this will work for you but in a similar case I do something like this and it works like a charm:
let isDataValid = Observable(false)

var questionViews:[KnowledgeQuestionView]! {
    didSet {
        let observables = questionViews.map {
            $0.isDataValid.toSignal()
        }

        combineLatest(observables) { elements -> Bool in
            /*
             iterate over elements and if any are false 'return false'
             */

            return true
        }).bind(to: isDataValid)
    }
}


Option to set Theme

By default, Accrescent uses the system theme, and both light and dark themes are supported. All that needs to be done here is adding a choice in the settings to choose between system, dark, or light theme.

And maybe a black theme too if dark isn't black.

And also remembering that if Dynamic You Theming is enabled, the option to manually choose theme should be unavailable for clarity.

I think in that case that element should be disabled, maybe with some note about it in description?


Update bstr to 1.X

Update the optional bstr dependency to 1.X, plus some clippy fixes.

This requires bumping the MSRV to 1.65. I will need to check if that move is doable.


fix(deps): update images to latest

This PR contains the following updates:

Package
Update
Change

icr.io/ext/sysdig/kspm-analyzer
patch
1.44.11 -> 1.44.16

icr.io/ext/sysdig/kspm-collector
patch
1.39.5 -> 1.39.6

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

:tada: This PR is included in version 1.3.13 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Running in a Jupyter notebook works nicely.  Running as a .py causes my computer to freeze due to insane cpu usage.

Running MolScribe in a Jupyter notebook works nicely for me.  Running the same code as a .py causes my computer to freeze due to insane cpu usage.
Running this piece of code on M1 Mac
model = MolScribe(f'{folder}/data/swin_base_char_aux_1m.pth', device=torch.device('cpu'))

def mol_scribe_osr(filepath):
    output = model.predict_image_file(filepath, return_atoms_bonds=True, return_confidence=True)
    return output['smiles']

Hi,
Running a Python script should have similar performance to running a Jupyter notebook locally.
To limit CPU usage, please see https://discuss.pytorch.org/t/how-to-limit-the-number-of-cpus-used-by-pytorch/67254/2

Hi Thomas,
Thanks for the quick reply.
I agree, it seems really odd that I see this difference.
I tried running torch.set_num_threads(2) directly before the function call and in a few other places but with no luck.   Looking in the activity monitor it seems 16 python processes are being launched (I have 10 cores - but 2 are slower).   Running the code in a Jupiter notebook only launches a single process.

@willfinnigan This might be related to #14, at least molscribe.chemistry.convert_graph_to_smiles spawns 16 processes as well


Problem on Android: cursor gets back after a fourth symbol

I'm using a simple mask for phone number:
jQuery(document).ready(function(){
  jQuery("#phone-test").inputmask("+7-999-999-99-99");
});

When I typing the number<PHONE_NUMBER> on Android (5.1 with Chrome, Sony Xperia Z), it fills the input field like this:
+7-987-543-10-26
First 3 numbers are ok. Then after I type the fourth number cursor moves before the fourth number (in this case it's 6, | symbol for cursor):
+7-987-|6_--
The same repeats after the eighth number (2 in the example):
+7-987-543-|26-__
So in the end it looks like +7-987-543-10-26
Why is it so messy and is there a fix for this bug?

As I haven't found any way to fix it, the only temporary 'fix' (actually it's not a fix) I could think of is to turn Inputmask off on Android devices:
jQuery(document).ready(function(){
	var ua = navigator.userAgent.toLowerCase();
	var isAndroid = ua.indexOf("android") > -1;
	if(!isAndroid) {
	  jQuery(selector).inputmask({
		mask: "+7 (999) 999-99-99"
	  });
	}
});

I hope soon the actual fix would be made/found, for the mask is a very nice way to improve UI.

@ShamanFromSiberia ,
Have a try with disabling predictive text

@ShamanFromSiberia ,
you can use autocomplete="off"

worked for me :)

not for me :(


[bug] jsonRpcProvider polls for both current network and previous network

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
0.5.5
Current Behavior
As I switch between networks while connected to my dapp, I see the polling requests being sent for both the current chain and the previous chain.
Expected Behavior
Requests should only be sent for the currently selected chain.
Steps To Reproduce

Load up dapp with wallet connected on mainnet. See polling requests being sent to the mainnet rpc url.
Switch network from mainnet to goerli. See polling requests being sent to both the goerli rpc url and the mainnet rpc url.
Switch network from goerli to mumbai. See polling requests being sent to both the mumbai rpc url and the goerli rpc url (the polling requests to mainnet stop).

Here's my json rpc provider config:
jsonRpcProvider({
  rpc: (chain) => {
    const rpcUrl = CHAIN_INFO[chain.id].rpcUrl
    const websocketUrl = CHAIN_INFO[chain.id].websocketUrl

    return {
      http: rpcUrl,
      webSocket: websocketUrl ? websocketUrl : undefined,
    }
  },
  pollingInterval: RPC_POLLING_RATE_MS,
  priority: 1,
  static: false,
})

I'm using the switchNetworkAsync function from useSwitchNetwork to change networks. And not sure if it matters, but for my testing I was connected to coinbase wallet.
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
No response

I'm having trouble reproducing this one! Could you create a reproducible example on CodeSandbox and then re-open the issue? Thanks!


New box-sizing rules break grid inside offcanvas menu content

I've mentioned that after new 5.5.2 release we have a bit new rules for box-sizing inheritance.
Commit: dd66a01bf2e37e713c545e468acdac3f8e5e6c87
Good change, but... as @gakimball had already mentioned it in #5819, this could cause wrong behavior for some elements that use another box-sizing type.
This is what happened to offcanvas menu content. Is it supposed that offcanvas should be now used for simple menus only? Because grids and full-width buttons have wrong sizes now.
I've checked sources, and it seems, that F5 uses different box-sizing for off-canvas-menu and off-canvas-submenu mixins only.

We're getting a lot of comments about this, so we're going to revert it. In the mean time, you can use this as a workaround:
*, *:before, *:after {
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
}

* has no specificity, so you should be able to drop this anywhere in your code.

And here you go. 82f75888006c0f141ac29c9bcd1f00d0f9e6c1fb

Thanks. Actually I've used a bit different workaround. F5 has non-border-box sizing in offcanvas menus only, so the fix is obvious:
// Don't allow menu children inherit 'content-box' box-sizing
.left-off-canvas-menu, .right-off-canvas-menu, .left-submenu, .right-submenu {
  & > * {
    @include box-sizing(border-box);
  }
}

@gakimball Could you bump Foundation to 5.5.3 because now that fix is available only on master branch and people who are using bower to manage their dependendies still will get buggy version.