Improve bounding sphere calculations

The current implementation of bounding sphere calculation works fine for meshes that have all welded vertices, but in calculation of meshes that have unwelded vertices, duplicate vertex positions offsets the bounding sphere center, resulting in the radius to be larger than is optimal.
I am presenting a solution to this, which is simple in concept: remove duplicate vertex positions from the positions list. The following Python script performs both the current calculations and new calculations and prints the result of both. The center is usually closer to vanilla, and at times, the most optimal, which can result in a more optimal bounding sphere radius.
import ssbh_data_py
import numpy as np

mesh = ssbh_data_py.mesh_data.read_mesh("model.numshb")

for o in mesh.objects:
    positions_mean_old = [0, 0, 0]
    positions_mean_new = [0, 0, 0]

    print(f'Name: {o.name}, Index: {o.sub_index}')

    # Current geometry_tools calculation
    for [x, y, z] in o.positions[0].data:
        positions_mean_old += np.array([x, y, z])
    print(f'Old: {positions_mean_old / len(o.positions[0].data)}')

    # Offered geometry_tools calculation
    for [x, y, z] in np.unique(o.positions[0].data, axis=0):
        positions_mean_new += np.array([x, y, z])
    print(f'New: {positions_mean_new / len(np.unique(o.positions[0].data, axis=0))}\n')

This script only generates the center of the sphere, but I'd have to bet the radius is more optimal as a result.

That approach might give better results in certain circumstances. I would have to look into it more to see if it's noticeably better in the general case. Some libraries assume this operation will be fast, so I'm hesitant to add any major performance changes.
The main issue with the suggestion is the use of np.unique. The current naive implementation runs in O(N) time where N is the number of vertices. This means that doubling the vertex count roughly doubles the running time. Sorting can ideally be done in O(N*log2(N)) time, which doesn't scale as well for large inputs. As N gets to be very large, this implementation will perform noticeable worse. Rather than 10x slower performance when going from 100 to 1000 vertices, we could see as bad as 15x slower performance.

N
N log2(N)

100
~664

1000
~9966

There are faster ways to find unique values, but sets and dictionaries don't always perform well in practice. I would have to do some benchmarks to see how big of a difference the sorting makes in practice. This is one of those problems where no one has found a fast exact solution. An exact solution would run extremely slowly for large models.
I may look into implementing one of the more widely known fast approximations at some point as an additional option to compute the bounding sphere. https://en.wikipedia.org/wiki/Bounding_sphere#Algorithms

My Python implementations were just a proof of concept which, if I provided comparisons, would demonstrate the differences and greater accuracies. I suppose if one is to offer a solution in a scenario like this, then they'd need to provide comparisons or benchmarks to prove their solution is effective. I will try to do that at a later time.
If you're favoring speed over accuracy, I would understand that. I just thought I'd point out a flaw with the current implementation in a specific case with some models. Though the option to calculate quickly or having a more precise bounding sphere would be a welcome option.

You'll need to be careful to clearly define "accurate" in this case. For matching the output of an existing program, it's likely the original authors are using an existing published algorithm. When comparing to the optimal solution, we usually mean the smallest sphere that encloses all the given points. Giving a formal proof for either of these cases would be very difficult. There are probably some Python implementations of common algorithms like Ritter's algorithm floating around the internet that may give closer results to what you were observing.
In the case of using bounding volumes for depth sorting objects, it's often not critical to compute the smallest possible bounding volume as long as the comparison between spheres produces the expected results. Sometimes a larger than optimal solution is good enough, but it depends on the context of course.


fix: select no entries

Thanks :)
Slight regression from fixing tons of small things in long session last night :sweat_smile:


Fuel wallet automatically removed from Chrome

What version of Wallet are you using?
0.7.2
What is happening?
After installation of Fuel Wallet it was removed from Chrome browser after some time
steps to reproduce

Install the wallet on Chrome browser
Make couple of transactions
Check after couple of days if wallet is visible in extensions

How it should behave?
Wallet should not be removed from any browser
What os are you seeing the problem on?
Windows Desktop
What browser?
Chrome
What is your browser version?
Version 112.0.5615.49 (Official Build) (64-bit)

@id120189 this is expected behavior from browsers and the installation is done by a zip file. In the future, it will not be true once the installation is done by Chrome Web Store.


Small fixes andygk63

Just a few small fixes. This would help me managing our main product (written in VFP) in our git repository. I hope this is the right way to ask für a fix.

Hey Andy!
I've added them to GitHub and to VFPx:
Look at version v1.19.48 Preview-1 and the changelog:
https://vfpx.codeplex.com/releases/view/116407
Thanks for the fixes! ;-)


Introduce QUIC as a p2p control plane

Currently, the client and gateway run two protocols on the UDP socket:

ICE
Wireguard

We already de-multiplex those on the same socket within snownet.
For all other communicate like DNS queries, we currently relay through the portal. I don't think that is particularly good. For example, we have no means of retrying a failed DNS query. See #4266.
For this and other reasons, I think we should introduce a dedicated control plane next to our data plane, i.e. multiplex another protocol next to ICE and wireguard. My suggestion for this would be to use QUIC (and use HTTP3 as an application protocol but we could also directly run DNS over QUIC for example).

QUIC has a SANS-IO implementation in the form of quinn-proto, allowing an easy integration into snownet. That will allow us to offer high-level APIs on a snownet::Node that directly communicates with the other node whilst hiding the details on how exactly that happens.
QUIC packets can also be very easily identified by their packet header, making de-multiplexing very easy and efficient.
QUIC also gives us multiplexing of several requests (meaning sending multiple requests at the same time), it is encrypted and we don't need to worry about retransmissions.

There are of course alternatives but IMO none of them are very attractive:

Send more stuff through the wireguard tunnel: Not reliable, so we need to do our own retransmission.
Use the existing control plane: Likely slower because 2 RTTs and doesn't scale well to many clients.
Multiplex something home-grown next to ICE and wireguard: Just re-inventing the wheel.

Once we have a dedicated control plane, we can:

Run DNS queries directly to the gateway
Send "goodbye" messages, allowing clients to connect to another gateway before that one shuts down
... your favourite usecase here that requires another communication channel ...

I think I agree with having a "p2p control plane" alongside the existing one with the portal. Then the portal is solely involved in authorizing, configuring, and setting up connections, and this new "p2p control plane" would be used for
However, I want to be really careful about adding an entire protocol stack to do this. Which protocols we use has non-engineering effects -- we have to document its architecture for things like compliance certifications (and our customers), and document which crypto it uses (if non-standard) to Apple and Google for example. If QUIC is blocked in Enterprise environments, for example, we may not want to find that out after we've invested the time to add it, because it will break network connectivity and not just be a blocked website.
I would prefer first trying to devise a scheme to do this within our own WireGuard tunnel. We have the peers already connected, we would just need to agree on a simple metadata API for peer to peer communication.
We already segment our CGNAT space into Resource and Node ranges, so a client should be able to send packets directly to its connected Gateway Peer IPs and they wouldn't conflict with Resources.
In fact, for DNS, we may even be able to get away with the following minimal solution:

when a client accesses a DNS resource, the portal finds us the gateway
WireGuard tunnel is established, client receives gateway's peer IP
Client forwards the gateway's peer IP, gateway then forwards the real query

I would prefer first trying to devise a scheme to do this within our own WireGuard tunnel. We have the peers already connected, we would just need to agree on a simple metadata API for peer to peer communication.

We can do this but it means we are limited to protocols that do their own retransmission / are designed to work over UDP. That is very unusual for a "control plane".

If QUIC is blocked in Enterprise environments, for example, we may not want to find that out after we've invested the time to add it, because it will break network connectivity and not just be a blocked website.

Personally, I don't want to support such behaviour so I wouldn't mind if we say, sorry, you can't use this product 🤷♂
Let them use their broken H2 stacks if they want to. The Internet of tomorrow is built on QUIC :)

we are limited to protocols that do their own retransmission

Open a tcp socket and receive JSON

Personally, I don't want to support such behaviour so I wouldn't mind if we say, sorry, you can't use this product 🤷♂

Ah, that would be nice.

Let them use their broken H2 stacks

Enterprises have legitimate reasons to inspect HTTP traffic within their organization, and it appears that blocking QUIC allows them to use their existing WAFs and DLP products to do this for HTTP/2 (using SSL intercept I assume). In many cases they're legally obligated to.
But it's not just Enterprises. It's hotel WiFis, Airports, etc. It would be good to have an idea of how often QUIC is blocked. But network admins do so because they know connections will fallback to HTTP/2.
If it turns out a non-trivial portion of our customers block QUIC or have employees on networks that block QUIC, we can't use it for any mission-critical transport. I think iCloud Private Relay uses QUIC under the hood, maybe we can see how that's performing. But that's a personal service, not sure if businesses are relying on it.
I would love to go all-in on QUIC, but we need more real-world data about how it behaves globally on networks that don't honor the same net neutrality laws we get to enjoy.
WireGuard isn't perfect either, but we do have a couple years of experience running it in production as a L3 network transport. The end-user impact of blocking WireGuard would be much higher than blocking QUIC (which usually enjoys graceful degradation in almost all cases).

we are limited to protocols that do their own retransmission

Open a tcp socket and receive JSON

That would mean doing holepunching for TCP which requires doing a simultaneous open which is a lot more flaky then UDP hole punching.

I would love to go all-in on QUIC, but we need more real-world data about how it behaves globally on networks that don't honor the same net neutrality laws we get to enjoy.

So should we start gathering data about it? I.e. just check if we can open a QUIC connection? We could use it for "nice" good-bye messages to allow clients to quickly detect when a gateway goes down!

That would mean doing holepunching for TCP which requires doing a simultaneous open which is a lot more flaky then UDP hole punching.

I meant inside the tunnel -- listen on the Gateway's Peer IP, after the client connects it will be able to send JSON over the WireGuard tunnel to a socket bound on the Gateway to that IP.
The gateway could then only respond to other peers on that TCP socket.

That would mean doing holepunching for TCP which requires doing a simultaneous open which is a lot more flaky then UDP hole punching.

I meant inside the tunnel -- listen on the Gateway's Peer IP, after the client connects it will be able to send JSON over the WireGuard tunnel to a socket bound on the Gateway to that IP.
The gateway could then only respond to other peers on that TCP socket.

Where does the TCP stack come from? We would have to impoort a userspace TCP implementation into connlib to generate the packets. All we send is UDP.
All the retransmission for application-level TCP is done by the kernel, we only get the resulting IP packets out of the TUN device.

If we open a TCP socket listening on the IP of our own TUN device, would the kernel route the traffic back to us as IP?
The could work but feels a bit wonky 😅

If we open a TCP socket listening on the IP of our own TUN device, would the kernel route the traffic back to us?

Hmm I don't think so --
The Rust process bound to the TUN ip would open a tcp listener and receive messages there. The inner src address is a client's TUN address. The outer is the client's src IP (or NAT device sec IP).
When replying, the gateway sends to the client's TUN ip.
So the connection is TUN - TUN.
There shouldn't be packet loops -- our CGNAT range is effectively one giant LAN and we're already occupying these routes.

If we open a TCP socket listening on the IP of our own TUN device, would the kernel route the traffic back to us?

Hmm I don't think so --
The Rust process bound to the TUN ip would open a tcp listener and receive messages there. The inner src address is a client's TUN address. The outer is the client's src IP (or NAT device sec IP).
When replying, the gateway sends to the client's TUN ip.
So the connection is TUN - TUN.
There shouldn't be packet loops -- our CGNAT range is effectively one giant LAN and we're already occupying these routes.

I was hoping for the answer to be Yes and I think you are saying it does. With "routing back to us", I meant that we receive those IP packets generated by the kernel's TCP implementation as IP packets on the TUN interface, despite our socket being bound in the TUN device.
We can try this. It will not fit well into the current design of the tunnel. Where we currently do IO (and thus would bind a TCP socket) is at the very upper layer of the tunnel where we don't have any connection state. But we will need one TCP socket per connection, thus introducing new mappings / state that we need to communicate with events (happy to walk you through the code if interested).
I also don't want to invent yet another framing protocol for multiplexing over TCP, i.e. https://github.com/libp2p/rust-yamux.
If we bind a separate socket already, we may as well just bind a UDP socket and run QUIC over it which does multiplexing for us. The double encryption shouldn't hurt because it is not the data path anyway. QUIC can multiplex over a single socket so at least, we don't need to jiggle multiple sockets around and quinn-udp's SANS-IO design may be possible to integrate such we can just emit two events:

TransmitNetwork: Sends the UDP packet on the actual network
TransmitTunnel: Sends the UDP packet on a socket bound to the tunnel

We may not even need a UDP socket for that? We could just make those IP frames ourselves. For UDP, that is trivial. That might make it possible to still integrate it into snownet, which would be much nicer from an API perspective. All we need is the src and target IP for a particular connection so we can grab those IP packets before forwarding them to the application.

We could even try to run QUIC normally and if it fails, fall back to run jt through the tunnel.
Report a diagnostic event to the portal and we get numbers for how often it is blocked :)

Hmm, I see -- yeah, I do see the appeal to slot in QUIC from a technical perspective. Let's keep this open to tackle at a later iteration. First we probably need much more CI coverage (esp on the clients) to be confident in making protocol changes.

Let's keep this open to tackle at a later iteration.

For sure! It was interesting to hash out anyway :)

First we probably need much more CI coverage (esp on the clients) to be confident in making protocol changes.

Making it part of snownet by hand-crafting IP packets would mean we can actually cover this through unit tests that don't do any IO super easily. We could use IPv4 or IPv6 link-local addresses for these packets as those are guaranteed to never be routed so they should never appear as actual user traffic. Because a tunnel is always directly between a client and a gateway, we'd also only need two of them! I don't think we can use the actual interface IPs for this because it could be traffic for an app running directly on the gateway.

Another acecdote https://news.ycombinator.com/item?id=39972836
I suspect it's not uncommon

First we probably need much more CI coverage (esp on the clients) to be confident in making protocol changes.

Making it part of snownet by hand-crafting IP packets would mean we can actually cover this through unit tests that don't do any IO super easily. We could use IPv4 or IPv6 link-local addresses for these packets as those are guaranteed to never be routed so they should never appear as actual user traffic. Because a tunnel is always directly between a client and a gateway, we'd also only need two of them! I don't think we can use the actual interface IPs for this because it could be traffic for an app running directly on the gateway.

If we do this, QUIC can't be detected because it is encrypted by WG. So we get all the benefits of having a proper multiplexing protocol and re-transmissions etc dealt with for us without people detecting and blocking it. It means we need to hand-craft the UDP packets so it can't be used for anything performance critical but I think that is okay? A p2p control plane doesn't need to offer great performance.
Having it all part of snownet means we can easily experiment in the future with running it along-side wireguard if we want or maybe even replace it.

Spoke to another user recently whose firewalls block QUIC by default. The reason is because they have a secure web gateway feature that doesn't support QUIC, so it blocks it, and expects browsers to fallback to HTTP/2 instead where they can do SSL interception.

After discovering the cause of #5605 is likely that the path through the API is slower than direct through Relays / to Gateway, and grappling with the scalability challenges in #5606, I think this channel can be an important solution for latency / scalability for messages that don't need to touch the DB.
Still not sold on QUIC from a pragmatic perspective (due to the Firewall and additional complexity) and would lean towards the absolute simplest side channel we can build over the existing WireGuard connection. We could use the same IPC mechanism as the Tauri clients since we already have that in the repo?

There are two ways we can run QUIC:

As separate UDP packets
Through the tunnel

The main reason I'd like to use QUIC is because we need a reliable stream and I don't want to implement a retransmit mechanism. We could use a userspace TCP socket if we find one that is sans-IO. There is already quinn-proto which is a sans-IO QUIC implementation so that should be easy to add.
If we run it through the tunnel, it will not be detectable and as long as we only use it for control messages, the double encryption should not be a problem.

We could use the same IPC mechanism as the Tauri clients since we already have that in the repo?

I'd honestly probably use HTTP instead. Better multiplexing and running an HTTP server over QUIC is (in theory) trivial.

We could use the same IPC mechanism as the Tauri clients since we already have that in the repo?

I'd probably use HTTP instead. Better multiplexing and running an HTTP server over QUIC is (in theory) trivial.

Something like:

snownet reserves a dummy IPv6 address for itself
Opens a sans-IO QUIC endpoint for each tunnel
All packets to that dummy IPv6 address are handed to the QUIC stack instead of being passed upwards to the rest of connlib
Each side layers an HTTP server + client over the QUIC endpoint
snownet can now send HTTP requests reliably for each connection

The alternative is to stick to UDP and implement our own retransmits like we do for STUN messages to the relay.
We are limited in packet size (I definitely don't want to implement fragmentation & ordering for this) then but for control messages that shouldn't be much for an issue.

It might be helpful to list some intended use cases for this tunnel.
Right now the need is to forward DNS queries to the Gateway. DNS already runs over UDP and handles unreliability for us, so the simplest way to solve that (without adding any more dependencies or processing overhead) is to just forward the DNS query to the Gateway's tunnel IP, and the Gateway handles in its tunnel stack / eventloop without having to open a socket. If the Gateway sees a DNS query with another peer IP as its source, it could map it to an allowed resource for that peer in a straightforward way with an additional message type for the eventloop right?
Adding another layer of encryption + protocol stack still feels horribly redundant and high overhead, especially for mobile clients where we have memory and energy constraints, no?

DNS already runs over UDP and handles unreliability for us

Only if there is no response. Currently, the client instantly responds to the DNS query with new IPs. We don't even know which gateway to contact at this point because we want to select the resource (and thus the site) based on the port and traffic filters, right?
So we need a reliable transport later to tell the gateway, which IPs correspond to which DNS resource. It is almost the other way round, a gateway would have to make a reverse DNS lookup to the client upon receiving traffic for an IP that it hasn't mapped yet.

It might be helpful to list some intended use cases for this control channel.

Definitely agree to this. My suggestion is based on the assumption that any form of control protocol needs a reliable transport layer.

Adding another layer of encryption + protocol stack still feels horribly redundant and high overhead, especially for mobile clients where we have memory and energy constraints, no?

There might be ways to disable the TLS stack of a QUIC implementation. We'd have to look into it.

We could start with that for now which would mean we only create_or_resuse_connection once per wildcard DNS Resource, and all of the "sub resources" it matches can be sent over the established WireGuard channel instead of through the API.

Would we not want to log an access for each subdomain of a wildcard resource?

Would we not want to log an access for each subdomain of a wildcard resource?

I suppose this is the tradeoff -- logging means writing to Postgres, which unfortunately means sending all access, subdomains included to us-east1.
This will require more discussion with @AndrewDryga but when we implement #2046 we will need to get those logs into other places. Maybe we have log sinks that aren't in Postgres so we can write them regionally. But those should be outside of the data path so that we don't incur this latency penalty having to going all the way to us-east1 for everything.

Would we not want to log an access for each subdomain of a wildcard resource?

I suppose this is the tradeoff -- logging means writing to Postgres, which unfortunately means sending all access, subdomains included to us-east1.
This will require more discussion with @AndrewDryga but when we implement #2046 we will need to get those logs into other places. Maybe we have log sinks that aren't in Postgres so we can write them regionally. But those should be outside of the data path so that we don't incur this latency penalty having to going all the way to us-east1 for everything.

Is there a reason it has to be synchronised with the access? The gateway knows when a client accesses a resource. It could fire-and-forget an event to the portal in the background about that.

Another option for a reliable transport could be to use SCTP. That is part of the WebRTC stack and is used for data channels there. str0m uses https://docs.rs/sctp-proto internally which is also sans-IO and would thus be possible to integrate nicely into snownet.
I haven't looked into it in detail, just skimmed the API. We would have to time-box it to see how difficult it is to integrate.


[SPARK-16847][SQL] Prevent to potentially read corrupt statstics on binary in Parquet vectorized reader

What changes were proposed in this pull request?
This problem was found in PARQUET-251 and we disabled filter pushdown on binary columns in Spark before. We enabled this after upgrading Parquet but it seems there is potential incompatibility for Parquet files written in lower Spark versions.
Currently, this does not happen in normal Parquet reader. However, In Spark, we implemented a vectorized reader, separately with Parquet's standard API. For normal Parquet reader this is being handled but not in the vectorized reader.
It is okay to just pass FileMetaData. This is being handled in parquet-mr (See https://github.com/apache/parquet-mr/commit/e3b95020f777eb5e0651977f654c1662e3ea1f29). This will prevent loading corrupt statistics in each page in Parquet.
This PR replaces the deprecated usage of constructor.
How was this patch tested?
N/A

This will be a legitimate change because this replaces the deprecated usage of constructor. Please let me cc @liancheng and @srowen as well as it is also partly about building.

Test build #63104 has started for PR 14450 at commit 3c46111.

Test build #63104 has finished for PR 14450 at commit 3c46111.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63104/
Test PASSed.

Test build #63145 has started for PR 14450 at commit 50cc80c.

Test build #63145 has finished for PR 14450 at commit 50cc80c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63145/
Test PASSed.

@HyukjinKwon to be sure, this is something you think should be back-ported to 2.0? it doesn't affect 1.x right?

Oh, I think this should not be backported to 2.0 and 1.x. In current releases, this is all being manually prevented in Spark itself (in here). Also, they use Parquet 1.7.0/1.6.0rc3 but this was fixed in Parquet 1.8.0 (assuming from PARQUET-251).
In master branch, this safeguard was removed with upgrading Parquet to 1.8.1 in SPARK-9876. So, I believe this PR is only related with the current master.

Merged to master


Detect esm only packages and generate ems style import

Suggestion
There are some pure esm packages like node-fetch@3 that I am  having troubles using. When such module is imported in typescript the import is transpiled to regular require that fails at runtime. The node-fetch module has a type:"module" in it's package.json that clearly states that the package is esm module. This indication can be used and the import should be unmangled to allow smooth pure esm packages usage. As this seems like a breaking change it can be enabled via tsconfig.json option

To expedite the triage process, we need everyone to follow the issue template and instructions.
When you clicked "Create New Issue", the issue form was pre-populated with a template and some instructions. We need you to read those instructions completely, follow them, and then fill in all the fields in that template.
We are not able to assist with issues that don't follow the template instructions as they represent a significantly larger amount of work compared to issues which are correctly specified. Thank you for understanding.


reintroduce static metamodel?

This is where we left off at on the static metamodel.  At one point, it was removed and deferred to next release, which was supposed to have been with the approval of @gavinking who had opened the original issue for it: #230  but based on recent comments in that issue I suspect that was missed and didn't happen.
If we do decide to bring this back, this pull includes all of the latest that we had for static metamodel, including the working TCK tests.  If I recall correctly, one of the items that remained under discussion was whether we should keep the pattern where the metamodel fields are static (as in this pull) versus switch to one where the fields are volatile.  The former is safer, but required additional code in the spec to facilitate it.
It should also be noted that we split out part of Attribute into SortableAttribute to avoid providing methods like .asc() and .desc() on attribute types that are not sortable, and similar for .ascIgnoreCase() and .descIgnoreCase().  I don't remember that aspect being controversial, but if it was, we could certainly omit SortableAttribute in a first version, in which case the user would need to rely on .name() to construct their own Sort instances.

If I recall correctly, one of the items that remained under discussion was whether we should keep the pattern where the metamodel fields are static (as in this pull) versus switch to one where the fields are volatile.

@njr-11 I would love it if you guys could find time to talk me through this. In JPA it's totally the responsibility of the provider to initialize fields of the metamodel, and so the metamodel interfaces are just interfaces. But it looks like you're proposing something a bit different here. That's fine, but I would like to understand how it impacts existing metamodel generators and interop with JPA.

I would love it if you guys could find time to talk me through this. In JPA it's totally the responsibility of the provider to initialize fields of the metamodel, and so the metamodel interfaces are just interfaces. But it looks like you're proposing something a bit different here. That's fine, but I would like to understand how it impacts existing metamodel generators and interop with JPA.

Relying on the provider was the original plan, and is still an option.  In this case the provider needs to initialize it if it wasn't already initialized (indicated by the Generated annotation).  I believe Otavio was thinking that some IDEs would offer a way to define and generate the fully implemented metamodel during development time.
@otaviojava and @gavinking Would it work to move the Jakarta Data meeting from Wednesday, Dec 20 to be at the same time this week on Wednesday, Dec 13?  We could use it to sort out what should happen with the static metamodel and whether some of it should be included in version 1.0.

In this case the provider needs to initialize it if it wasn't already initialized

Yeah right that's the way it works in JPA.

I believe Otavio was thinking that some IDEs would offer a way to define and generate the fully implemented metamodel during development time.

Yeah so I would like to understand the thinking there.

Would it work to move the Jakarta Data meeting from Wednesday, Dec 20 to be at the same time this week on Wednesday, Dec 13?

I can make it, the only thing is I have a hard cutoff at the 55 minute mark.

Would it work to move the Jakarta Data meeting from Wednesday, Dec 20 to be at the same time this week on Wednesday, Dec 13?

I can make it, the only thing is I have a hard cutoff at the 55 minute mark.

@otaviojava If this works for you as well (it does for Gavin and myself), go ahead and move the Jakarta Data meeting to Dec 13 (I'll make sure to log on early enough to check if I need to start it up) for discussion.  If not, we can aim to discuss at the scheduled meeting on the following week.

Would it work to move the Jakarta Data meeting from Wednesday, Dec 20 to be at the same time this week on Wednesday, Dec 13?

I can make it, the only thing is I have a hard cutoff at the 55 minute mark.

@otaviojava If this works for you as well (it does for Gavin and myself), go ahead and move the Jakarta Data meeting to Dec 13 (I'll make sure to log on early enough to check if I need to start it up) for discussion. If not, we can aim to discuss at the scheduled meeting on the following week.

Sorry, I saw the message now.

Another point, IMHO: a good point to start should be the Jakarta Persistence API.
Basically, copy/paste what they have and start from there.
But, not to this version, to the following version.

Sorry, I saw the message now.
Did you talk?

Otavio - we did not have any meeting to discuss this last week because you did not respond beforehand and you need to be there to work out with Gavin what is acceptable and which release it will be in. We can discuss it this week instead.  The update that I just pushed is only a rebase onto latest, not any additional changes.

Folks, do you think we could set up a time to talk through this after the xmas period?

There is a Jakarta Data meeting scheduled for Wednesday, January 6, where we would discuss this if both of you are available for it.

The latest updates to the proposed metamodel reflect changes that were discussed at the January 3 meeting.

@otaviojava and @KyleAure This pull is updated with the review comment that you spotted as well as the JavaDoc correction that we noted on the Jakarta Data meeting earlier today.

@otaviojava could you complete your review of this so that we can merge it to enable Kyle to move forward with creating Milestone 3?

@otaviojava could you complete your review of this so that we can merge it to enable Kyle to move forward with creating Milestone 3?

As I said, I will need more time to test it deeply.
I am ok to move it forward, remembering our agreement:

Move this static metamodel forward.
The spec also allows all the info to be generated at build time.
We agree to be open to breaking compatibility in the next version if needed.

it is became huge.
So I will merge this one and create threads with scenarios.


Upgrade rspec, fix other warnings.

Current tentative plan: Direct people still on rails 3 to either use the rubygems.org version (1.1.2) or the tag I added to this repo a couple weeks ago (v1.1.3) as desired.  Given that there haven't been a lot of changes to this repo in the past year I don't anticipate any needed bugfixes to support rails 3, so I think we can just declare this gem to be rails 4 or higher for any future commits, starting with this branch getting merged.
In the worst case, there aren't a lot of backwards-incompatible changes so we could just create a branch that "reverts" to rails 3 and add any needed bugfixes there.

Hi David and Ed, I'm going to be closing out this PR in favor of the one from our working rails 4.0 branch.

Works for me.  Glad to see progress on this.


Files from root://submit50.mit.edu are not available at coffea-casa through XCache

Files from root://submit50.mit.edu are not available at coffea-casa through XCache:
>>> import uproot
>>> uproot.open("root://xcache//store/user/mariadlf/nano/D02/GluGlu_HToPhiGamma_M125_TuneCP5_PSWeights_13TeV_powheg_pythia8+RunIISummer20UL18MiniAODv2-106X_upgrade2018_realistic_v16_L1v1-v3+MINIAODSIM/8EDDE712-E106-7B48-AB0B-7E4580426E8E.root")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/lib/python3.9/site-packages/uproot/reading.py", line 141, in open
    file = ReadOnlyFile(
  File "/opt/conda/lib/python3.9/site-packages/uproot/reading.py", line 580, in __init__
    self._source = Source(
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 272, in __init__
    self._open()
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 275, in _open
    self._resource = XRootDResource(self._file_path, self._timeout)
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 83, in __init__
    self._open()
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 92, in _open
    self._xrd_error(status)
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 118, in _xrd_error
    raise OSError(
OSError: XRootD error: [ERROR] Operation expired
in file root://xcache//store/user/mariadlf/nano/D02/GluGlu_HToPhiGamma_M125_TuneCP5_PSWeights_13TeV_powheg_pythia8+RunIISummer20UL18MiniAODv2-106X_upgrade2018_realistic_v16_L1v1-v3+MINIAODSIM/8EDDE712-E106-7B48-AB0B-7E4580426E8E.root

I checked and I could open any other file:
>>> uproot.open("root://xcache//store/mc/RunIISummer20UL17NanoAODv2/TTToSemiLeptonic_TuneCP5_13TeV-powheg-pythia8/NANOAODSIM/106X_mc2017_realistic_v8-v1/120000/2A2F4EC9-F9BB-DF43-B08D-525B5389937E.root")
<ReadOnlyDirectory '/' at 0x7f171a2c23a0>

@jthiltges dom you have an idea what could be an issue?

I'm getting the impression that submit50.mit.edu storage isn't part of the CMS XRootD data federation. Looking at the MIT redirector, I'm not getting a result:
$ xrdfs xrootd.cmsaf.mit.edu ls /store/user/mariadlf
[ERROR] Server responded with an error: [3011] Too many attempts to gain dfs read access to the file

That /store/mc data file is available at Purdue and FNAL:
$ xrdfs xrootd.unl.edu locate '/store/mc/RunIISummer20UL17NanoAODv2/TTToSemiLeptonic_TuneCP5_13TeV-powheg-pythia8/NANOAODSIM/106X_mc2017_realistic_v8-v1/120000/2A2F4EC9-F9BB-DF43-B08D-525B5389937E.root'
af-a00.cms.rcac.purdue.edu:1098 Server ReadWrite
cmsxrootd-site1.fnal.gov:1094 Manager Read
cmsxrootd-site3.fnal.gov:1094 Manager Read
cmssrv608.fnal.gov:1094 Manager Read
cmsxrootd-site2.fnal.gov:1094 Manager Read

It should work OK to access the submit50 data directly with the full URL to the storage server, but not through the xcache.

@jthiltges it doesn't work also with full URL since submit50 doesn't support tokens:
cms-jovyan@jupyter-oksana-2eshadura-40cern-2ech:~$ python
Python 3.9.18 | packaged by conda-forge | (main, Aug 30 2023, 03:49:32)
[GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import uproot
>>> uproot.open("root://submit50.mit.edu//store/user/mariadlf/nano/D02/GluGlu_HToPhiGamma_M125_TuneCP5_PSWeights_13TeV_powheg_pythia8+RunIISummer20UL18MiniAODv2-106X_upgrade2018_realistic_v16_L1v1-v3+MINIAODSIM/8EDDE712-E106-7B48-AB0B-7E4580426E8E.root")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/lib/python3.9/site-packages/uproot/reading.py", line 141, in open
    file = ReadOnlyFile(
  File "/opt/conda/lib/python3.9/site-packages/uproot/reading.py", line 580, in __init__
    self._source = Source(
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 272, in __init__
    self._open()
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 275, in _open
    self._resource = XRootDResource(self._file_path, self._timeout)
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 83, in __init__
    self._open()
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 92, in _open
    self._xrd_error(status)
  File "/opt/conda/lib/python3.9/site-packages/uproot/source/xrootd.py", line 118, in _xrd_error
    raise OSError(
OSError: XRootD error: [FATAL] Auth failed: No protocols left to try
in file root://submit50.mit.edu//store/user/mariadlf/nano/D02/GluGlu_HToPhiGamma_M125_TuneCP5_PSWeights_13TeV_powheg_pythia8+RunIISummer20UL18MiniAODv2-106X_upgrade2018_realistic_v16_L1v1-v3+MINIAODSIM/8EDDE712-E106-7B48-AB0B-7E4580426E8E.root

Should we maybe talk with administrators of MIT submit50 and ask if they are interested in enabling tokens support?

@jthiltges ah it will not help us, right? it looks like we need to support x509 at coffea-casa?


Error after botfront login

Describe the bug
Here is the report:
Version: 0.27.0
Path: /project/bf/dialogue
Trace: TypeError: Failed to fetch
    in TypeError: Failed to fetch
    in Unknown
    in Suspense
    in d
    in div
    in Unknown
    in div
    in t
    in div
    in t
    in div
    in div
    in B
    in ForwardRef
    in ForwardRef
    in Connect(Component)
    in c
    in Unknown
    in RouterContext
    in Router
    in o
    in c
    in t
    in DocumentTitle
    in SideEffect(DocumentTitle)
    in $

To Reproduce
Steps to reproduce the behavior:

npm install -g botfront
mkdir mybot
cd mybot && botfront init
botfront up
Go to http://localhost:8888
Enter log in details and sign in
See error

Desktop (please complete the following information):

OS: Ubuntu 20
Browser : Chrome
Version: 86.0.4240.75 (Official Build) (64-bit)

If I quickly click other menu options, it doesn't crash. Thus it seems there is something broken in the dialogue option

Check the docs to set ROOT_URL
Le mer. 14 oct. 2020 05 h 11, Ian Kahwai<EMAIL_ADDRESS>a
écrit :

If I quickly click other menu options, it doesn't crash. Thus it seems
there is something broken in the dialogue option
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/botfront/botfront/issues/781#issuecomment-708270386,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4GAKXRNO7BO67VYBNEO7TSKVTMBANCNFSM4SQKP4SQ
.

That worked @znat


Add launch file for skeleton tracker

Not added to startup script because:

it only runs on herb2
it's an optional (and not lightweight) process

tf2 is generally unhappy with frames that start with a slash. Does this work with head/skel_depth_frame?

Yup, that works. Done.


Add support laravel 6.0

I'll actually merge it into a separate branch because the code is pretty much unmaintaned and i fear those broken tests.

https://github.com/rennokki/befriended/pull/50

thank you @rennokki


refactor(execution): type of additional_data in test_validate_accounts_tx

This change is

Prep for #1486.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (fdfba79) 69.42% compared to head (d76dc9a) 69.42%.

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

Additional details and impacted files
@@              Coverage Diff              @@
##           main-v0.13.1    #1485   +/-   ##
=============================================
  Coverage         69.42%   69.42%
=============================================
  Files                59       59
  Lines              8081     8081
  Branches           8081     8081
=============================================
  Hits               5610     5610
  Misses             2013     2013
  Partials            458      458

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

crates/blockifier/src/transaction/test_utils.rs line 197 at r1 (raw file):
Previously, giladchase wrote…
It's just in a test, so you can be liberal with clones (unless it's for really huge stuff).
Remove the reference and use additional_data.clone() in the test every time you initialize the struct

It is even simpler than that. Sorry for not going with the simpler design (from r2) in the first place. Done.
The other other option is to .clone() default_args every time.


Feature/datagrid phase3 additional string filter defs

Description

How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

hello, added 2 additional filter defs for string...... "not contains" and "not equals"  also added unit tests.  let me know if anything else is required.


Update concepts-server-logs.md

The name of log is already updated on Azure Portal. Changing to correct name, "PostgreSQL Server Logs"

@sunilagarwal
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Benchmarks

Beginnings of some benchmarks.
Using the experimental API. Building can be disabled via CMake option (BUILD_BENCHMARKS) which defaults to ON. But can be set to OFF.
Comments welcome.

Duplication is intentional. These are self contained benchmarks as much as possible. One can be changed without, hopefully, changing the others.
In terms of style, yes, can run clang-format.

A better way to manage the clang-format is to format the entire repo upon a merge. So, I will let you all do that once merging. Or if that is not OK, let me know and I can update once it is ready to merge.

I think it's better to run a clang-format before merging so the impending repo-wide clang-format changes as little as possible.
Is this ready to merge otherwise? Could you post the output of the benchmarks, just curious how they look. I'd like @lehecka to take a look too.

I don't have changes planned. If ready to merge, I can format it.

pulling this in. We will reformat it in another iteration.

Just a capture of current benchmark output. I removed the request name and removed the 64 request run for reqrespthroughput. And moved to override instead of virtual. The rest is as is.
Results are on Mac OS.
Baseline
Run on (8 X 2900 MHz CPU s)
2017-04-13 12:45:13
Benchmark                                   Time           CPU Iterations
-------------------------------------------------------------------------
BM_Baseline_TCP_Throughput/40/1024       8762 ns       3357 ns     216761   63.5628MB/s   1.58907M items/s
BM_Baseline_TCP_Throughput/40/4k         9478 ns       3529 ns     214601   64.3907MB/s   1.60977M items/s
BM_Baseline_TCP_Throughput/80/4k         9184 ns       3630 ns     199456   122.022MB/s   1.52527M items/s
BM_Baseline_TCP_Throughput/4k/4k         2267 ns       1741 ns     404330   2.19156GB/s    561.04k items/s
BM_Baseline_TCP_Latency/32              19351 ns       6524 ns     106706   4.67801MB/s   149.696k items/s
BM_Baseline_TCP_Latency/128             20120 ns       6724 ns     103871   18.1535MB/s   145.228k items/s
BM_Baseline_TCP_Latency/4k              20053 ns       6748 ns     100815   578.845MB/s   144.711k items/s

All the rsocket benchmarks have an abort at the end when the server goes out of scope. The rsocket server isn't cleaning up appropriately. But it does not interfere with the benchmarks. So, I will omit the output accept to illustrate it below.
Assertion failed: (eventBase_ == nullptr || eventBase_->isInEventBaseThread()), function stopAccepting, file io/async/AsyncServerSocket.cpp, line 186.
Abort trap: 6

Stream Throughput
Run on (8 X 2900 MHz CPU s)
2017-04-13 12:45:44
Benchmark                                      Time           CPU Iterations
----------------------------------------------------------------------------
BM_RsFixture/BM_Stream_Throughput/8          170 ns        147 ns    4613215   100.001k items/s Message Length: 32
BM_RsFixture/BM_Stream_Throughput/32         150 ns        137 ns    4763168   196.577k items/s Message Length: 32
BM_RsFixture/BM_Stream_Throughput/128        148 ns        134 ns    4920291   262.582k items/s Message Length: 32

Request/Response Throughput (I removed 64 in my branch because it is not any different)
Run on (8 X 2900 MHz CPU s)
2017-04-13 12:45:55
Benchmark                                              Time           CPU Iterations
------------------------------------------------------------------------------------
BM_RsFixture/BM_RequestResponse_Throughput/1       78519 ns      70740 ns       9385    13.805k items/s Max Requests: 1, Message Length: 32
BM_RsFixture/BM_RequestResponse_Throughput/2       43978 ns      38873 ns      17375   25.1218k items/s Max Requests: 2, Message Length: 32
BM_RsFixture/BM_RequestResponse_Throughput/8       26621 ns      23948 ns      28586   40.7789k items/s Max Requests: 8, Message Length: 32
BM_RsFixture/BM_RequestResponse_Throughput/16      23054 ns      21403 ns      27297    45.628k items/s Max Requests: 16, Message Length: 32
BM_RsFixture/BM_RequestResponse_Throughput/32      23261 ns      20891 ns      32884   46.7463k items/s Max Requests: 32, Message Length: 32

Request/Response Latency
Run on (8 X 2900 MHz CPU s)
2017-04-13 12:46:08
Benchmark                                        Time           CPU Iterations
------------------------------------------------------------------------------
BM_RsFixture/BM_RequestResponse_Latency      78720 ns      70628 ns       9636   13.8268k items/s Message Length: 32

Todd, I am unable to win the fight with the FB open source tooling / CLA to be able to land this PR to fbcode under your account. Would you be ok if I duplicate the PR under my name and land this?

awesome work btw. Its very helpful for us to have the benchmark.

@lehecka feel free to land it however is easiest.

closing in favor of https://github.com/ReactiveSocket/reactivesocket-cpp/pull/340


Activating/deactivating a feature does not immediately affect the rendered output

The (textual) buffer contents change, but the rendered output does not change until I move the cursor to a different line and back.

Yes, the partial shaping stuff keeps state in a very dirty way to try to get the right glyphstring to the SVG renderer. I need to make sure the output component gets re-rendered when things change and when the user hovers over a table row.

I've fixed the state-change issue (not deployed yet), but there's another problem: Harfbuzz.js is sometimes ignoring my feature string!


Expanded RabbitMQ patterns

While at it, I fixed the date parsing for Postgres.

I'm merging directly, @adnanrahic. But please let me know if you see anything wrong and I can change later.


Map frame lost when pure_localization

Hello,
First of all thanks for the work done.
I have been working with the cartographer the last months and I have been able to set up almost everything and made it work really good.
Now I am working with the pure localization node, but I am having problems time to time with it.
The point is that for some reason the pure localization node stops sending the "map" transform after a while, and therefore the link between "base_link" and "map" gets lost and the pure localization stops. Although the weird thing is that I do not received any message from cartographer telling that the node has crashed.
Thanks in advance.
Kind Regards.

What kind of crash did you experience? Any error messages or stack trace?

It just stops sending the transform, that was the weird thing, cartographer did not send any crash message I got the feeling that it was still running but the connection between the base_link of the robot and the map_frame sent by the cartographer disappeared and it is not able to take it back again so cartographer gets disconnected form my robot description.
I know it is a weird  but  any idea of what could be causing this error will be helpful. This is the last message I got before loosing the track of the frames:
[ INFO] [1539869984.708266908]: I1018 15:39:44.000000  8478 motion_filter.cc:42] Motion filter reduced the number of nodes to 15.6286%.
[ INFO] [1539869989.513644053]: I1018 15:39:49.000000  8478 collated_trajectory_builder.cc:72] imu rate: 99.95 Hz 1.00e-02 s +/- 4.73e-03 s (pulsed at 100.58% real time)
[ INFO] [1539869989.513731481]: I1018 15:39:49.000000  8478 collated_trajectory_builder.cc:72] odom rate: 7.47 Hz 1.34e-01 s +/- 2.11e-02 s (pulsed at 99.94% real time)
[ INFO] [1539869989.513797148]: I1018 15:39:49.000000  8478 collated_trajectory_builder.cc:72] scan rate: 29.99 Hz 3.33e-02 s +/- 2.28e-03 s (pulsed at 100.75% real time)

As you can see no error messages are received. I tried fixing it by increasing the odom rate because it seems too low, but the error still occurred.
Thanks for your quick response and your help.

Ok, thanks for your help!
I will track this issue and report the outcomes in case it is helpful for other people.
Kind Regards

Hello,
I discovered that the error occurs when I use both cartographer and move-it since ther is a robotic arm mounted on the mobile robot.
Don't know the reason why this is happening but it is for sure due to this.
Best Regards

Hello,
I found the problem.
As I am using an actual robot (no simulation) I had this problem with the frames due to the use_sim_time parameter set to true: A I was not simulating anymore It is clear that this parameter should be set to false. Doing this the problem vanished.
Thanks a lo for your kind help, and of course for the amazing job you have done with cartographer.


Optimize the loading and migration of global_config

Our current global_config is not complete enough. We need to complete the following features:

auto migrate when the column add to global_config
support default value if the column not in etcd
simpler editing tools and support migrate column

optional tool: https://github.com/spf13/viper

We may try to solve this problem through deploying and upgrading helm release.


Debug swift unit test display: "No symbol info"

Which OS: Ubuntu 16.10
Which LLDB version (lldb -version):
lldb version 4.0.0 (git@github.com:apple/swift-lldb.git revision e0208d67b0e643d2067964ebb510a0fb38536445)
 Swift-3.1 (revision 228feb1ee06152ec4ed1b3d6a497f92b172eaf67)
 clang revision a27f59eceefa3b4d60ab1133081662c4a25a43fb
 llvm revision a568eff4bfe5ff38a98bb1f8a00480449beec6ec

Which VSCode version (Help/About): 1.10.2
What is the problem and how did you get there:

Install Swift 3.1 for Ubuntu 16.10
Open a project generate with SwiftPM
Put a breakpoint on Tests/ModuleName/UnitTest.swift
Configure debug like this:

{"configurations": [
    {
        "type": "lldb",
        "request": "launch",
        "name": "Swift Test",
        "program": "/usr/bin/swift",
        "args": ["test"],
        "cwd": "${workspaceRoot}"
    }
]
}

Start debugger
Stop and display

What did you expect to have happened instead (if not obvious):

Display Swift source where is the breakpoint

I am not a Swift dev, but I'd guess that your code does not actually run in the context of the "swift" process. /usr/bin/swift is probably a compiler driver that invokes swiftc to build your program, then launches the produced binary.
You'll need to find out where that binary is located and debug it directly.

@vadimcn swift test build the sources and generate a dynamic library. This dynamic library is loaded by swift test. I don't have a binary that I can debug directly. I guess I have to change something on the launch.json. May be you can help me 🙂

swift test build the sources and generate a dynamic library. This dynamic library is loaded by swift test

So I did a quick test on my Mac, and it appears that switch test first spawns /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-test, which in turn spawns /Applications/Xcode.app/Contents/Developer/usr/bin/xctest <my package>PackageTests.xctest.
When I launched the latter in debugger, my breakpoints worked as expected.
I bet Linux toolchain does something similar.

@vadimcn on linux I don't find any xctest 😔

Sorry, I don't have Linux Swift.   You can create a test with a long sleep, run it, then examine the process tree with ps -efH.

@TofPlay: Were you able to resolve your issue?

Not yet. I'm busy on another project...

Maybe you can build XCTest yourself.

Assuming you are using SwiftPM (and it would seem you are since you can run swift test) then you need to look for the test executable. The test executable should be found in the .build directory (assuming you have not messed with that default).
For instance, on my machine while debugging a package called Ogra I made a config that looks like this:
{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "program": "${workspaceRoot}/.build/debug/OgraPackageTests.xctest",
            "args": [],
            "cwd": "${workspaceRoot}"
        }
    ]
}

This makes the breakpoints work and it seems to understand the symbols.
Unfortunately this only gets part of the way. The variables when inspected all say <not available>. @vadimcn if you have any further suggestions I would be interested in working with you.

@RLovelett: the issues you've linked to appear to be about C++ include directories; it seems unlikely that this would affect debug symbols.
I would try to figure out if LLDB has loaded the symbols for your test binary using commands like target modules list and image dump symfile.

@RLovelett

Assuming you are using SwiftPM

Yes 😁
I change my launch.json like you suggest and it works 👍 😋

This makes the breakpoints work and it seems to understand the symbols.
Unfortunately this only gets part of the way. The variables when inspected all say .

Same for me 😞

Are you sure these tests are compiled with the right flags (i.e. on optimization, with debug info)?

@vadimcn by default swift test build the debug version:
--configuration, -c     Build with configuration (debug|release) [default: debug]
$ swift test --help
OVERVIEW: Build and run tests

USAGE: swift test [options]

OPTIONS:
  --build-path            Specify build/cache directory [default: ./.build]
  --chdir, -C             Change working directory before any other operation
  --color                 Specify color mode (auto|always|never) [default: auto]
  --configuration, -c     Build with configuration (debug|release) [default: debug]  <<<<<<<<<<<
  --enable-prefetching    Enable prefetching in resolver
  --list-tests, -l        Lists test methods in specifier format
  --parallel              Run the tests in parallel.
  --skip-build            Skip building the test target
  --specifier, -s         Run a specific test class or method, Format: <test-module>.<test-case> or <test-module>.<test-case>/<test>
  --verbose, -v           Increase verbosity of informational output
  -Xcc                    Pass flag through to all C compiler invocations
  -Xlinker                Pass flag through to all linker invocations
  -Xswiftc                Pass flag through to all Swift compiler invocations
  --help                  Display available options

Well, my thinking is this: if you can debug regular Swift programs, but not tests, it must be down to some difference in compilation flags, right?
Otherwise... I am afraid I out of ideas here.  I don't do any Swift development, let alone on Linux.

@vadimcn I can't debug any Swift program on Linux; even a simple "Hello, world!" compiled in debug mode. It does not matter if I use LLDB directly or I use your plugin. I am fairly well versed in the Swift compiler and runtime though I know next to nothing of how to use LLDB. It is a magic black box for me. That's what has me tripped up right now.
I will definitely checkout target modules list and image dump symfile though. Those are two commands I have never tried (mostly because I don't know what they are).

I can't debug any Swift program on Linux;

Ahh, sorry, I missed this bit.

I know next to nothing of how to use LLDB

What about GDB?  Does it have the same problem?  If so, I'd suspect something being wrong with debug info rather than the debugger.

@vadimcn On Ubuntu 16.10 I generated an application with SwiftPM and I executed the commands. The application and output of lldb are in the zip file. I hope this will help you 🙂
ubuntu16.10-swift3.1-lldb-test.zip

@vadimcn to build, test and debug the application on Ubuntu 16.10 with Swift 3.1 you can use my docker image:
$ docker run -ti --rm --name swift31 -v /<folder where is App>:/projects --privileged=true tofdocker/swift31:1.0
...
root@0d52060a28f6:/# swift --version
Swift version 3.1 (swift-3.1-RELEASE)
Target: x86_64-unknown-linux-gnu
root@0d52060a28f6:/# lldb --version
lldb version 4.0.0 (git@github.com:apple/swift-lldb.git revision ab05d1ed7cd81032110419ed8be77aa721ff62df)
  Swift-3.1 (revision 2dddbaf9c390094e37b45d83419ecf61d3707667)
  clang revision 9772bf511a32353fad73e38fdfc501d5fccb50d2
  llvm revision a7c680da5182d29e2c6441d484a307b695902c64
root@0d52060a28f6:/# cd /projects/
root@0d52060a28f6:/projects# ll
total 12
drwxr-xr-x 7 root root  238 Apr 12 18:40 ./
drwxr-xr-x 1 root root 4096 Apr 12 18:46 ../
drwxr-x--- 8 root root  272 Apr 12 18:40 .build/
-rw-r--r-- 1 root root   41 Apr 11 17:02 .gitignore
-rw-r--r-- 1 root root   96 Apr 11 17:02 Package.swift
drwxr-xr-x 3 root root  102 Apr 11 18:12 Sources/
drwxr-xr-x 2 root root   68 Apr 11 17:02 Tests/
root@0d52060a28f6:/projects# rm -rf .build
root@0d52060a28f6:/projects# swift build
Compile Swift Module 'App' (1 sources)
Linking ./.build/debug/App
root@0d52060a28f6:/projects# lldb .build/debug/App
(lldb) target create ".build/debug/App"
Current executable set to '.build/debug/App' (x86_64).
(lldb)

(Image generated with the project TofPlay/Dockerfiles)

From the log file you've attached, it looks like Swift did not include any debug info for local variables.   Sorry, can't help you more here.

@vadimcn I continue my tests on linux with my docker environment tofdocker/swift31:1.1
Issue with global variables 😰

I put a break point on ligne 4 and try to see variable with instruction frame variable
App# rm -rf .build
App# swift build
Compile Swift Module 'App' (1 sources)
Linking ./.build/debug/App
App# lldb ./.build/debug/App
(lldb) target create "./.build/debug/App"
Current executable set to './.build/debug/App' (x86_64).
(lldb) l
   1   	var lInt = 1
   2   	var lString = "String"
   3
   4   	print("Hello, world!")
(lldb) breakpoint set --line 4
Breakpoint 1: where = App`main + 88 at main.swift:4, address = 0x0000000000400b88
(lldb) run
Process 69 launched: './.build/debug/App' (x86_64)
Process 69 stopped
* thread #1, name = 'App', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400b88 App`main at main.swift:4
   1   	var lInt = 1
   2   	var lString = "String"
   3
-> 4   	print("Hello, world!")
(lldb) frame variable
(lldb)

As you can see we have a bug because we can not see any global variables. For this error I creadted [SR-4638]
frame variable works with classes and functions 👍 😁

I put a break point on ligne 5 and try to see variable with instruction frame variable
App# swift build
Compile Swift Module 'App' (1 sources)
Linking ./.build/debug/App
App# lldb ./.build/debug/App
(lldb) target create "./.build/debug/App"
Current executable set to './.build/debug/App' (x86_64).
(lldb) l
   1   	public class Test {
   2   	  public var string:String = "default"
   3
   4   	  public func changeString(_ pValue:String) {
   5   	    self.string = pValue
   6   	  }
   7   	}
   8
   9   	public func main() {
   10  	  let lVar = Test()
(lldb) breakpoint set --line 5
Breakpoint 1: where = App`App.Test.changeString (Swift.String) -> () + 24 at main.swift:5, address = 0x0000000000400c68
(lldb) run
Process 122 launched: './.build/debug/App' (x86_64)
Process 122 stopped
* thread #1, name = 'App', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400c68 App`Test.changeString(pValue="Value from the main", self=(string = "default")) -> () at main.swift:5
   2   	  public var string:String = "default"
   3
   4   	  public func changeString(_ pValue:String) {
-> 5   	    self.string = pValue
   6   	  }
   7   	}
   8
(lldb) frame variable
(String) pValue = "Value from the main"
(App.Test) self = 0x0000000000415c20 (string = "default")
(lldb) next
Process 122 stopped
* thread #1, name = 'App', stop reason = step over
    frame #0: 0x0000000000400ca2 App`Test.changeString(pValue="Value from the main", self=(string = "Value from the main")) -> () at main.swift:6
   3
   4   	  public func changeString(_ pValue:String) {
   5   	    self.string = pValue
-> 6   	  }
   7   	}
   8
   9   	public func main() {
(lldb) next
Process 122 stopped
* thread #1, name = 'App', stop reason = step over
    frame #0: 0x0000000000400def App`main() -> () at main.swift:12
   9   	public func main() {
   10  	  let lVar = Test()
   11  	  lVar.changeString("Value from the main")
-> 12  	}
   13
   14  	main()
(lldb) frame variable
(App.Test) lVar = 0x0000000000415c20 (string = "Value from the main")

As you can see variable frame works with classes and functions
You could probably use it in vscode-lldb 😉


[Story] Add confirmation email

Epic: #17
Description
As a user I want to confirm that the email address I use for my account to belongs to me, so that no one else can use my email address for an account.
Tasks

[ ] Add email service.
[ ] Add send confirmation email function.
[ ] Add confirmation function.

The plan changed, confirmation email will be implemented with Duende Identity Server instead.


AD User: Password does not meet requirements

Version: <IP_ADDRESS>5
OS/Distro: Ubuntu server 16.04
Issue/Impact:
I've logged in with an Active Directory (= AD) user, which works just fine. Then I've tried to change the password from the Linux system, but I always get the error message, that the password does not meet the requirements even when it does.
I've tried to change the password like this:
ad.user@ubuntu:~$ passwd
ad.user@ubuntu:~$ /opt/pbis/bin/passwd
We've tried to use a password, which is using a workmate with his Windows notebook. This password was accepted by our current password policy on Windows, but not on Linux.
AD Password Policy Settings:
My AD has following password policies:

Enforce password history: 2 passwords remembered
Maximum password age: 90 days
Minimum password age: 0 days
Minimum password length: 10 characters
Password must meet complexity requirements: Enabled

Output/Error:
Both above commands did not change the password in the Active Directory and returned the same message:
Current password:
New password:
Re-enter password:
Password does not meet requirements:
passwd: Authentication token manipulation error

Steps to Reproduce:

Login as AD user in Ubuntu
Try to change the password of the AD user
Use one of the above commands to change the password

Thanks for your quick reply. My /etc/pam.d/common-passwd contains this:
password	[success=2 default=ignore]	pam_lsass.so
password	[success=1 default=ignore]	pam_unix.so	obscure	try_first_pass	sha512
password	requisite					pam_deny.so
password	required					pam_permit.so
password	optional		pam_encryptfs.so

Any solutions for my problem, @rbest-bt?

Not at this time. This is on my list to investigate. Currently we are working on getting the 8.6.0 release out

I'm having the same issue, is there a solution?

This is still an issue. Can we try to get this resolved please? What information is required from us, I will gladly provide.

pbis-open will longer receive updates and will be archived. Closing all outstanding issues. Please consider BeyondTrust Active Directory Bridge for continued support.
https://www.beyondtrust.com/privilege-management/active-directory-bridge


RadioButton is not displayed correctly when selected

Bug, feature request, or proposal:
Bug.
What is the expected behavior?
When a radiobutton is selected, the radiobutton is painted with an inner circle, i.e.:

...

And this inner circle is visible like so:

What is the current behavior?
This inner circle is not visible.  I have isolated it down to the CSS.  This is how it comes up initially, and the inner circle is not painted to indicate the selection:

The CSS that causes this is here:

If I tweak the CSS, it works, the selection is clearly visible:

The CSS for this rendition is here:

The difference in CSS is this.
Broken:

Working:

What are the steps to reproduce?
This works: https://stackblitz.com/edit/angular-material2-issue-k42ecg
But in my dev environment, it does not.  So, I am reasonably certain that I am doing something wrong, but I am not sure what or how to fix it.  This occurs in a newly configured project and also an older one.
My local setup is as follows:
package.json:
{   "name": "radio",   "version": "0.0.0",   "license": "MIT",   "scripts": {     "ng": "ng",     "start": "ng serve",     "build": "ng build",     "test": "ng test",     "lint": "ng lint",     "e2e": "ng e2e"   },   "private": true,   "dependencies": {     "@angular/animations": "^5.1.0",     "@angular/cdk": "^5.0.0",     "@angular/common": "^5.0.0",     "@angular/compiler": "^5.1.0",     "@angular/core": "^5.1.0",     "@angular/forms": "^5.0.0",     "@angular/http": "^5.0.0",     "@angular/material": "^5.0.0",     "@angular/platform-browser": "^5.0.0",     "@angular/platform-browser-dynamic": "^5.0.0",     "@angular/router": "^5.0.0",     "core-js": "^2.4.1",     "rxjs": "^5.5.2",     "zone.js": "^0.8.14"   },   "devDependencies": {     "@angular/cli": "1.5.0",     "@angular/compiler-cli": "^5.0.0",     "@angular/language-service": "^5.0.0",     "@types/jasmine": "~2.5.53",     "@types/jasminewd2": "~2.0.2",     "@types/node": "~6.0.60",     "codelyzer": "~3.2.0",     "jasmine-core": "~2.6.2",     "jasmine-spec-reporter": "~4.1.0",     "karma": "~1.7.0",     "karma-chrome-launcher": "~2.1.1",     "karma-cli": "~1.0.1",     "karma-coverage-istanbul-reporter": "^1.2.1",     "karma-jasmine": "~1.1.0",     "karma-jasmine-html-reporter": "^0.2.2",     "protractor": "~5.1.2",     "ts-node": "~3.2.0",     "tslint": "~5.7.0",     "typescript": "~2.4.2"   } }
.angular-cli.json is untouched.
Thank you for helping out!  Much appreciated.

Please refer all troubleshooting questions to our community at StackOverflow, Angular Material mailing lists, Gitter, etc. We try to keep our issues here only open for bugs and feature requests.


BFF calls the new endpoint in authorization api to check if the user has the required rights that he is delegating to the system user ( Delegationcheck)

Before the user approve the creation of a system user, the BFF should check with AM if both the set of Rights are delegable by this user, and that the user has the Role "Tilgangsstyrer"
### Tasks
- [ ] https://github.com/Altinn/altinn-authentication/issues/607

Lukker, for det kommer en ny variant av denne som gjør denne deprecated


chore(jest): update dependencies

v14.13.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


gamma: drop provision to omit backendRef

What type of PR is this?
/kind gep
What this PR does / why we need it:
IMO, this does not make sense as SHOULD. It should be a MUST or not in the spec.
I have proposed removal for the following reasons:

Inconsistent with Gateway parent ref (which also means you cannot possibly have a service parent and gateway parent)
Limits ability to have non-Service parents, as it implies the frontend and backend are the same object

Does this PR introduce a user-facing change?:

NONE

@robscott @michaelbeaumont @keithmattix @mikemorris

https://github.com/kubernetes-sigs/gateway-api/blob/a8826b8dec2f1ea40a4fa067a04d23c44c168916/geps/gep-1426.md?plain=1#L164-L169
Doesn't requiring backendRefs make the "all ports" option significantly less useful? Or is there a use case to direct multiple frontend ports to the same backend port?

Doesn't requiring backendRefs make the "all ports" option significantly less useful? Or is there a use case to direct multiple frontend ports to the same backend port?

I would say yes, and I think that is the most compelling reason to keep it if we do. But I would note this is a fairly narrow UX optimization; once they start using a different backend (example - canary) then they lose this enhancement. It seems a like a possible foot-gun that to change the backend from svc to svc-v1=50%, svc-v2=50% I need to change the parentRef and backendRef, for example.

Doesn't requiring backendRefs make the "all ports" option significantly less useful? Or is there a use case to direct multiple frontend ports to the same backend port?

I would say yes, and I think that is the most compelling reason to keep it if we do. But I would note this is a fairly narrow UX optimization; once they start using a different backend (example - canary) then they lose this enhancement. It seems a like a possible foot-gun that to change the backend from svc to svc-v1=50%, svc-v2=50% I need to change the parentRef and backendRef, for example.

👍 can we drop the optional port for Service parentRefs if we drop optional backendRefs? Then ideally "missing port & kind: Service" in a parentRef would be rejected by the webhook.
But the status quo of optional parentRef port and optional backendRefs works for me.

@howardjohn I think if we do remove this we should clearly note why it was removed and provide very clear guidance for how the situation should (or must) be handled. Removing the "SHOULD" without actually leaving any guidance for how to handle this case could result in more confusion and inconsistency across providers.

It should be done gateway-api wide then IMO. It's not gamma specific to
have no backendRef (if we merge this, anyways).
Which the answer will be a 500 error I think
On Wed, May 17, 2023, 2:42 PM Rob Scott @.***> wrote:

@howardjohn https://github.com/howardjohn I think if we do remove this
we should clearly note why it was removed and provide very clear guidance
for how the situation should (or must) be handled. Removing the "SHOULD"
without actually leaving any guidance for how to handle this case could
result in more confusion and inconsistency across providers.
—
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/gateway-api/pull/2031#issuecomment-1552122410,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXIK33ONN7YPEKBJRHLXGVA5LANCNFSM6AAAAAAYFTFTEM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Add back removed line and explained this was removed


[release-0.23] Update the manifests and dependencies for 0.23

/test pull-knative-operator-eventing-upgrade-tests


impl ToString for Value

Rustc_serialize's Json does not have this. @s-panferov is this still something that you think would be valuable to you?

@dtolnay to string is already implemented in #63 because Display is implemented.
https://doc.rust-lang.org/std/string/trait.ToString.html

This trait is automatically implemented for any type which implements the Display trait. As such, ToString shouldn't be implemented directly: Display should be implemented instead, and you get the ToString implementation for free.

Ah perfect. Thanks again for your PRs.

@dtolnay thanks for review! Now it's much easier to migrate from rustc-serialize to serde_json and even support them both because they implement common traits.


Memory leak in version 1.22.0

Describe the issue
Memory usage spiked when we deployed our application with postgres-nio 1.22.0.
Vapor version
4.102.1
Operating system and version
Linux
Swift version
Swift 5.10
Steps to reproduce
Run a Swift backend application that uses postgres-nio and compare the memory usage when on 1.21.5 and 1.22.0.
Outcome
Memory usage steadily increases after starting an application that uses postgres-nio 1.22.0.
Additional notes
We observed this on an instance that runs recurring jobs but does not receive web traffic, so memory usage tends to be stable over time.
In the attached screenshot, the first release to include postgres-nio 1.22.0 was on July 26. The sudden drops in memory usage indicate when new releases went live, restarting the app. The graph stabilizes on July 30 when we reverted postgres-nio to 1.21.5.

Edit: I'm not sure if the memory usage spikes in 1.21.6 or 1.22.0.

Repro (No need to even do a query):
@main
struct EntryPoint {

    static func main() async throws {
        let config = PostgresClient.Configuration(...)
        let client = PostgresClient(configuration: config)

        try await withThrowingTaskGroup(of: Void.self) { taskGroup in
            taskGroup.addTask {
                await client.run()
            }

            taskGroup.addTask {
                for idx in (0..<100_000) {
                    if idx % 10 == 0 {
                        print(idx)
                    }
                    try await Task.sleep(for: .milliseconds(10))
                    try await client.withConnection { conn in
                        /// No need to even do a query
                    }
                }
            }

            try await taskGroup.waitForAll()
        }
    }
}

No need to even be able to create a proper connection?:
@main
struct EntryPoint {
    static func main() async throws {
        let config = PostgresClient.Configuration(
            host: "",
            port: 5432,
            username: "",
            password: "",
            database: "",
            tls: .disable
        )

        let client = PostgresClient(configuration: config)

        try await withThrowingTaskGroup(of: Void.self) { taskGroup in
            taskGroup.addTask {
                await client.run()
            }

            taskGroup.addTask {
                for idx in (0..<100_000) {
                    if idx % 10 == 0 {
                        print(idx)
                    }
                    try await Task.sleep(for: .milliseconds(10))
                    try await client.withConnection { conn in

                    }
                }
            }

            try await taskGroup.waitForAll()
        }
    }
}

I'll just add that memory leak instruments in Xcode is reporting a leak when profiling my backend code.

Okay, found the source of this leak:
With 1.22.0 we started to forward write promises:
https://github.com/vapor/postgres-nio/blob/d18b137640222fe29a22568077c4799d213fdf96/Sources/PostgresNIO/Connection/PostgresConnection.swift#L545
However in the success case we never forward them to the wire in the PostgresChannelHandler.
https://github.com/vapor/postgres-nio/blob/d18b137640222fe29a22568077c4799d213fdf96/Sources/PostgresNIO/New/PostgresChannelHandler.swift#L199

Would it maybe make sense to revert the commit that has caused the leak before the fix PR is approved and merged in?

Any update on this? This likely affects vast majority of web servers written in Vapor, and it's been broken for three weeks now. When can we expect it to be fixed and merged in? Or should I pin to the previous version of postgres-nio for now?

@LukasCZ thanks for pinging. Will prepare a revert pr for now.

PR is up: https://github.com/vapor/postgres-nio/pull/501

Thank you @fabianfett 🙏


Continue splitting headers. - [merged]

In GitLab by @perarnau on Mar 20, 2019, 11:26
Merges split-more-headers -> master
See #27 for info.

In GitLab by @perarnau on Mar 20, 2019, 13:17
added 2 commits
e7e2bea3 - [refactor] move dma implem to separate headers37c7cd9f - [refactor] move scratch implem to separate headers
Compare with previous version
By Swann Perarnau on 2019-03-20T18:17:14 (imported from GitLab project)

In GitLab by @perarnau on Mar 20, 2019, 14:02
added 2 commits
5d939f2c - [refactor] move dma implem to separate headersc466f1da - [refactor] move scratch implem to separate headers
Compare with previous version
By Swann Perarnau on 2019-03-20T19:02:39 (imported from GitLab project)

In GitLab by @perarnau on Mar 20, 2019, 14:28
mentioned in commit 41667393fa06dff98b60a032b3a3c76137d05686
By Swann Perarnau on 2019-03-20T19:28:11 (imported from GitLab project)

In GitLab by @perarnau on Mar 20, 2019, 14:28
merged
By Swann Perarnau on 2019-03-20T19:28:10 (imported from GitLab project)


Add new domain zskv.cz

Added new domain zskv.cz

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


fix(doc): Updating getting-started default constructor strategy

Hello,
I noticed that you changed the default constructor strategy from "always" to "auto", so I updated the documentation
I hope that's OK for you
Have a great day

Thanks for the typo :)


not found page issue fixed

@Aleesha-azhar can you add screenshot of how this looks?

@Aleesha-azhar can you add screenshot of how this looks?

yes,  sure

screenshot


Test(web-react): Refactor prefix testing into more general provider test

Waiting until https://github.com/lmc-eu/spirit-design-system/pull/232 will be merged.
TODO:

[ ] Refactor also TextField tests


Updated Code is not executing

Type: Bug
When I am running the code in the browser, the brower only gives output of old code and not the updated code.
 It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

/needsMoreInfo
How do you run code in browser? With an extension or some other way?

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

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


Add support for runtime name in the Runtime Generator

Changes in the Runtime Generator..minor fixes
fixes #2244

Could you add a test like this to check that content in package.json ?
Then, LGTM

Could you add a test like this to check that content in package.json ?

I'll do so in short order ❤👍

Yes, it works merging it! Thanks 🚀


chore: remove duplicate

What this PR does / why we need it:
Follow-up PR，remove duplicate to simplify the code.
Which issue(s) this PR fixes:

Fixes #2481

/retest


Fixes foreign key

Related to https://github.com/cjmellor/approval/discussions/67
It containes failing tests (before the fix), as a proof of the bug

Thanks @Temepest74 !


Add unit test for punt to CPU with subquery

Added a quick unit test to repro the issue fixed by #318.
@dpayne Would you mind taking a look?

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

That should trigger it. My specific query was a CTE e.g. WITH some_table ( ... ) ..., but this should also trigger it.


Show servers with failed healthchecks in dashboard

Do you want to request a feature or report a bug?

Feature

What did you do?
Run the following docker-compose.yml:
version: '3'

services:
  reverse-proxy:
    image: traefik:latest
    command: --api.insecure=true --providers.docker --log.level=DEBUG
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  httpbin:
    image: kennethreitz/httpbin
    labels:
      - traefik.http.routers.httpbin.rule=Host(`httpbin.docker.localhost`)
      - "traefik.http.services.httpbin.loadbalancer.healthCheck.path=/status/500"

What did you expect to see?
I would expect to see some kind of error on the dashboard (maybe under Services).
What did you see instead?
No errors shown on the frontpage or in the services list:

You can only see the failing healtcheck, when opening the service's page:

Output of traefik version: (What version of Traefik are you using?)

See docker-compose.yml.
If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
N/A

duplicate of #6117


Remove main content from User Provisioning section

Azure AD users do not need to be provisioned manually - they are automatically provisioned the first time they log into the Gigya Console.

@iandotha,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

@iandotha, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, Microsoft Pull Request Bot

@iandotha : Thanks for your contribution to the Azure documentation! The author, @jeevansd, has been notified to review your proposed change.

#sign-off


Update sign.go

Support No AWS kinesis. For local developing
If you want to use a sandbox(not in AWS). It's custom URL with not 3 point
Fix https://github.com/sendgridlabs/go-kinesis/issues/58

Can this be merged? I realize there are some pending cosmetic changes, so if that's the blocker let me know and I'll send a new PR.

Closed by https://github.com/sendgridlabs/go-kinesis/pull/64


[simdjson] Update to 0.4.6

Describe the pull request

What does your PR fix? Fixes https://github.com/simdjson/simdjson/issues/981

Which triplets are supported/not supported? Have you updated the CI baseline?
arm-uwp and x86-windows are supported now. Yes.

Does your PR follow the maintainer guide?
Yes.

Ready for review now?

Ready for review now?

Yes.

Hi! @JackBoosY Please review again. The upstream has issue several patch releases recently since v0.4.1, so I need to update this PR to catch up the upstream.

LGTM, thanks for the PR!


⚠ Jenkins Plugins Artifactory has degraded performance

In d68c6c8, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1154 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 789c59e after 25 minutes.


Move docker stack docs out of experimental

docker stack {deploy,ls,ps,rm,services} are no longer experimental.

Also, we need to update https://github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md

@AkihiroSuda I can update the page. Where should it be moved to?

I think the DAB / Bundles format is still in experimental, so the file probably doesn't have to be moved, but slightly modified to explain that only the DAB format is experimental

@thaJeztah OK, this is getting too complicated for me. I cannot tell the exact state of the dab format, of support in compose and registry. Let's keep this document out of scope of this PR. Some official guy should take over :grin:.

@albers no problem, thanks for taking care of this part!


allow args to be passed to internal oidc-js

ping @shaunluttin

Thank you for this. As far as I can tell it isn't a breaking change. :shipit:
I am going to start merging more pull requests without too much scrutiny. I will take a closer look before bumping the version and pushing it to NPM.


Fix two small bugs in param tag options parsing.

This PR fixes a two small bugs that I noticed in how descriptions are handled in @param tags, particularly when there are tag options containing double-quoted strings.

The DESCRIPTION_MATCHER regex in ParamTag was greedy-matching the paired " character. It should be non-greedy. I was getting a description of Whether this should be on or not" { value_type: "Boolean on my parameter in the UI.
The DESCRIPTION_MATCHER was getting passed to gsub! rather than sub! when it matched, so the tag option string getting passed to YardTag looked like { choices: [primary, secondary], value_type: } instead of { choices: [primary, secondary], value_type: "Symbol" } because the "Symbol" was being removed by gsub.

I added a couple of tests for options in the ParamTag spec. They will both fail if the implementation changes in here are removed. I wouldn't be surprised at all if there were some other odd bugs that could be turned up with some more thorough tests though!

@GabeIsman many thanks for this! My regex-fu is pretty poor so PRs like this are much appreciated :-) There is probably a much better way to do the @param tag string parsing tbh but it might be a while before I get around to reworking it.
I'll check it out in a bit more detail now and then get it merged and out in the next release. Thanks again 🙏

@GabeIsman this all looks good... although diving back into that parsing code makes me want to cry a bit 😂
I've found another bug while testing out your fixes (not as a result of your fixes though!) but I'm going to merge this and then fix it in a separate PR/commit.
Thanks :-)

Thanks for reviewing and merging @allmarkedup! Happy to help out as I can.


Implementation of asynchronous mocking

TODO

tests

Was just going to ask about this. Awesome to see it in progress :)

@gingermusketeer I was in two minds about the API as it's not a use case I have. Does it look sensible to you?

@wheresrhys It looks sensible to me. I will be making use of this now that it has been merged. Let you know if anything comes up

@wheresrhys This worked perfectly. Thanks


Docker: add Dockerfile

Alternative to Jib, we could generate a simple Dockerfile at the root folder of generated project
Could be done in same context than Docker with Jib

@pascalgrimaud for this is there any specific requirement for Dockerfile content ? or we can go with very basic setup as below
FROM openjdk:17-slim
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

it's a little bit more complex. I'd like the build part in this Dockerfile, so I can do: docker build -t xxxx .
 && \
    sleep ${JHIPSTER_SLEEP} && \
    java \
        ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom \
        -jar /jhipster-registry.jar

COPY --from=builder /jhipster-registry.jar .

Hello @beatfreaker, did you work on this ?

@matthieulapatate Yes, creating PR in some time, sorry was caught with something so couldn't push the code


Update faq.rst

Fixing #2789

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

Comparison is base (d6a1d2b) 76.35% compared to head (69ad41f) 76.33%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2809      +/-   ##
==========================================
- Coverage   76.35%   76.33%   -0.03%
==========================================
  Files          88       88
  Lines        9672     9672
  Branches     2062     2062
==========================================
- Hits         7385     7383       -2
- Misses       2020     2021       +1
- Partials      267      268       +1

see 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_9epoh35gfm/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_9epoh35gfm/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_9epoh35gfm/clone/recipe/meta.yaml:37: missing_pip_check: For pypi packages, pip check should be present in the test commands
Errors were found


Option to hide ZSH_VERSION?

Love the work here! Thanks so much for it.
Would you be to open to an option to hide the ZSH_VERSION here?

Yes, I would. I've just pushed a new version which includes this. Thanks for the suggestion

Thank you!


Not able fetch Account propertys  via API call

Good afternoon, I am unable to get some values when calling API - ListUsers
Here is my API call:
/client/api?accounttype=0&apiKey=api_key&command=listUsers&name=murzik2&response=json&signature=sign
But it's always return empty response.
but if you use admin instead of murzik2, all information about this account is provided
CloudStack 4.17.02
so my question is it possible to get AccountID via API Call, if i have only AccountName ?
Thx

@happyalexkg
You need to pass the domainid which can be fetched by listDomains api.

Thank you very much ... BIG thx


Getting Object Layers with Keys

object layers are instead of being retrieved through indexs we are retrieving them through keys, the key is the name of the layer.
Closing #24

Discussed, Going to be changing the way Layers are parsed in as guards.


waitFor - multiple events

Hello,
This is more of a question than a bug.  I've just started looking at using workflow-es and it looks straightforward for my needs.
However, I've been trying to play around with the idea of a workflow that would have multiple waitFor steps but that are not sequential (that is, think of 3 people having to "approve" the workflow before it could enter the step - those approvals could be in any order).
While I can put multiple waitFor steps in, the engine seems to get confused.
I have thought about using a "while" but I would still need to persist some data to know when all of the previous events had been triggered.
[sorry if you prefer this type of question via a different forum]

Hi,
You might be able to achieve this with a .forEach step, as it runs the children in parallel
https://github.com/danielgerlag/workflow-es/blob/master/es2017-guide.md#parallel-foreach
Let me know if this helps?

I was also looking at for-each (basically I am running up each of the examples in my own test environment and playing with them to understand how it all operates).
I think I can do it in a single event. If I were to execute some code in that step that checked all the conditions then returned true or false, that should control the execution of the next step - correct?
Also, I am struggling to get the OUTCOME sample working. Maybe I am not understanding what it should be doing.  I am guessing it is supposed to be checking the 'result' returned as the outcome in the first step. But that doesn't seem to be working.
Other than these few gaps, I am really liking how tidy this code is. Thanks for making it open source.

I'll close this for now(although I am still stuck on the 'outcome' example) as I have worked out a way to do this with the waitFor sitting inside a while. Something like this...
.startWith(...)
.while(/* exit state is not reached */)
  .do((this)=>then
    .startWith(...)
      .input((step,data)=>{...})
      .output((step,data)->{
        // the output step can check if the final compound state is reached in related data
        // and set an appropriate variable that is checked in the .while()
        ...
      })
      .waitFor("interim-event", data=>data.myId)
    .then(...)
  )
.then(/* finished */)
)

Hi Gary,
This project is actually a port of it's .NET counterpart - which is a little further ahead in terms of features...
That version has a .Parallel() feature:
https://github.com/danielgerlag/workflow-core/wiki/06.-Control-Structures#parallel-paths
I can look into updating workflow-es with some of the functionality that I have put into the .NET version?

Hi Daniel,
I was wondering about a Parallel feature (although I am pretty sure I can handle my use-case with the sample flow above).
I noticed you had a version across a number of platforms.  I also wondered if you had worked from any core references for the architecture.


Implement event notifications

Agile Requirement
On the event page, during the pre-reveal phase, a user can sign up for event notifications. The form will be shown below the hero.
Description
Create a new personalized form Block that will allow users to complete the different fields, the dtata will be sent to a Form Handler that will provide a success (confirmation) message validating their suscription to the event or an error message.
Acceptance Criteria

Triggered by “notify me” button on event page -> clicking on notify me acts as an anchor link to the form below on the page
Modal does not obscure navigation
Form with following elements:
Title "Be the first to see the all-new Volvo VNL"
Subtitle "Sign up here to be notified about the digital reveal on January 23rd at 1 PM EST"

Text field “First name”
Text field “Last name”
Text field “ZIP code”
Text field of type e-mail “E-mail”
Checkbox to confirm agreement to Privacy Policy -> If the user does not check it, the "notify me button will remain inactive".
Link to Privacy Policy will be placed in a paragraph below checkbox, for accessibility purposes, upon click, they will be open in a separate tab.
Submit button “Notify me”, connected to Pardot endpoint (Form Handler).

Success and error handling similar to #43

Form details

Styling will be done in #43 (floating labels), but the alignment of the form fields needs to be created:

On mobile: all form items below each other
On tablet:

two columns with a 16px gutter
vertical gutter between form fields and checkbox is 40px

On desktop:

two columns with a 20px gutter
vertical gutter between form fields and checkbox is 48px

All form items are required:

Which will add an asterisk to the labels, see #43
Basic client-side form validation is being done by the browser
Form validation is implemented in the client's side.

“Add event to calendar” triggers user’s default calendar client, see #72

To be determined

[x] Figure out whether we switch from modal to linking to a section on the same page
[x] Form validation from Pardot.

Decision: The modal is not necessary. Need to create a web form (vs iFrame).

Because this form is so personalized and need the custom validation message, we need more flexibility so we decided to develop a custom form.

Technical details:

FYI @ryanropero , can you implement a form handler (with same settings success, error and kiosk/data entry mode as subscribe to newsletter form handler) mapping to these fields below, please?

Please let us know the form handler url and the names you have used over this thread once is created to start testing.

Form handler: https://go.pardot.com/l/1038333/2023-11-27/8hmb
Field names:

Where marketing_consent can be true | false
+honeypot field added in the forms block.

confirmed as done


⚠ ClamAV has degraded performance

In 8c79bac, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 73 ms

Resolved: ClamAV performance has improved in 9690267.