The message was not consumed even if it was

Contact Details
No response
Version
8.x
On which operating system(s) are you experiencing the issue?
Windows
Using which broker(s) did you encounter the issue?
Azure Service Bus
What are the steps required to reproduce the issue?
1. Message is send to topic/queue
2. Azure function consumes message
3. _receiver.Handle is executed
4. exception "The message was not consumed" is thrown
5.  Message is successfully processed.

What is the expected behavior?
Messages should be consumed without throwing exception
What actually happened?
Exception " The message was not consumed" is thrown while consumers and sagas are correctly handled.
I want to handle simply scenario where I have :
one queue testCommands where two commands Command and Command2 are send. Function3 subscribes to that queue and TestConsumer : IConsumer and TestConsumer2 : IConsumer consumes those commands.
Also I have two topics eventreceived and eventreceived and events from those topics should be handled by TestSaga
All messages reach appropriate functions and to consume them I use
IMessageReceiver
await _receiver.Handle("testCommands", command, cancellationToken);
at first I didn't add any configuration and because of that only one type of message was handled.
For example when I ran the azure function app and sent Command as first message, it was handled without any errors, but when I sent Eventreceived as next, "The message was not consumed" exception was thrown and message went to dead-letter queue. The same scenario happened when I sent Eventreceived as first event. It was handled by the saga and then when handling Command as next "The message was not consumed" exception was thrown and command ends in dead-letter queue
            (context, cfg) =>
            {
                cfg.ReceiveEndpoint("testCommands", x =>
                {
                    x.ConfigureConsumer<TestConsumer>(context);
                    x.ConfigureConsumer<TestConsumer2>(context);
                    x.ConfigureConsumeTopology = false;
                });

                cfg.SubscriptionEndpoint("default", "functionapp2/eventreceived", x =>
                {
                    x.ConfigureSaga<TestState>(context);
                });

                cfg.SubscriptionEndpoint("default", "functionapp2/eventreceived2", x =>
                {
                    x.ConfigureSaga<TestState>(context);
                });
            });

now every message is consumed, but "The message was not consumed" exception is constantly thrown.
So either i messed with configuration badly or there is a bug
Related log output, including any exceptions
[2022-12-29T20:16:45.487Z] SEND sb://x.servicebus.windows.net/testCommands 18110000-7565-54ee-fdc3-08dae9d99b88 FunctionApp2.Command
[2022-12-29T20:16:45.488Z] Executing 'EConsumer3' (Reason='(null)', Id=83fdbf34-0327-4b0f-b3c8-720333712a0c)
[2022-12-29T20:16:46.610Z] Trigger Details: MessageId:<PHONE_NUMBER>6554eefdc308dae9d99b88, SequenceNumber: 61, DeliveryCount: 1, EnqueuedTimeUtc: 2022-12-29T20:16:45.1960000+00:00, LockedUntilUtc: 2022-12-29T20:17:45.1960000+00:00, SessionId: (null)
[2022-12-29T20:17:05.130Z] SKIP sb://x.servicebus.windows.net/testCommands 18110000-7565-54ee-fdc3-08dae9d99b88
MassTransit.MessageNotConsumedException: sb://x.servicebus.windows.net/testCommands => The message was not consumed
   at MassTransit.Middleware.FaultDeadLetterFilter.Send(ReceiveContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/FaultDeadLetterFilter.cs:line 11
   at MassTransit.Middleware.DeadLetterFilter.MassTransit.IFilter<MassTransit.ReceiveContext>.Send(ReceiveContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/DeadLetterFilter.cs:line 39
   at MassTransit.Transports.ReceivePipeDispatcher.Dispatch(ReceiveContext context, ReceiveLockContext receiveLock) in /_/src/MassTransit/Transports/ReceivePipeDispatcher.cs:line 62
   at MassTransit.Transports.ReceivePipeDispatcher.Dispatch(ReceiveContext context, ReceiveLockContext receiveLock) in /_/src/MassTransit/Transports/ReceivePipeDispatcher.cs:line 97
   at MassTransit.Transports.ReceivePipeDispatcher.Dispatch(ReceiveContext context, ReceiveLockContext receiveLock) in /_/src/MassTransit/Transports/ReceivePipeDispatcher.cs:line 103
   at MassTransit.AzureServiceBusTransport.ServiceBusMessageReceiver.Handle(ServiceBusReceivedMessage message, CancellationToken cancellationToken, Action`1 contextCallback) in /_/src/Transports/MassTransit.Azure.ServiceBus.Core/AzureServiceBusTransport/ServiceBusMessageReceiver.cs:line 62
   at FunctionApp2.Function3.Run(ServiceBusReceivedMessage command, CancellationToken cancellationToken)
[2022-12-29T20:17:09.993Z] Executed 'EConsumer3' (Failed, Id=83fdbf34-0327-4b0f-b3c8-720333712a0c, Duration=24489ms)
[2022-12-29T20:17:09.999Z] System.Private.CoreLib: Exception while executing function: EConsumer3. MassTransit: sb://x.servicebus.windows.net/testCommands => The message was not consumed.
[2022-12-29T20:17:10.311Z] Message processing error (Action=ProcessMessageCallback, EntityPath=testCommands, Endpoint=x.servicebus.windows.net)
[2022-12-29T20:17:10.313Z] System.Private.CoreLib: Exception while executing function: EConsumer3. MassTransit: sb://x.servicebus.windows.net/testCommands => The message was not consumed.
[2022-12-29T20:17:12.631Z] RECEIVE sb://x.servicebus.windows.net/testCommands 18110000-7565-54ee-fdc3-08dae9d99b88 FunctionApp2.Command FunctionApp2.TestConsumer(00:00:02.1850187)

Link to repository that demonstrates/reproduces the issue
https://github.com/agolaszewski/massfunctions/tree/main/FunctionApp2/FunctionApp2

My topology


[FR] localize Security Chaos Engineering

@sestegra
Can i work on Security Chaos Engineering in French' ?
Best
Seb'

@seb-835  The issue is yours!


[WIP] Use struct for colors

Instead of having 3 different variables, put all the colors in a struct. Just wanted to get your input before I go further with this. I'm thinking that more could be done with change, i.e. maybe put the old_background_color inside the struct as well and maybe change the logic for that....
Also I have yet to fix the indentation.

I like this :+1:

Maybe put the old_background_color inside the struct as well

Yes, that would be nice.
You can also drop color postfix from struct members as it is already clear from struct name that it is color.

Also I have yet to fix the indentation.

Check out clang-format - in most distributions it's part of a clang package. To fix indentation & coding styles you just  run clang-format -i [file_name] and that's it.

All comments have been adressed, removed the postfix and fixed the indent.

I think we misunderstood each other. By:

Maybe put the old_background_color inside the struct as well

I imagined having struct like this:

Ah so you mean to have another instance of the same struct for the old variables, that makes sense.

All comments adressed :)

Thanks :slightly_smiling_face:


Fix NPE for non-existent workflow

#2643 followup
Introduced this in my PR to allow workflows and services to have
the same path. Noticed the exception when refreshing services
locally.

This will be handled in PR #2720


Check semantic errors.

implementation of #8

If the SYNOPSIS shows an optional option-argument (as with [ -f[ option_argument]] in the example), a conforming application shall place any option-argument for that option directly adjacent to the option in the same argument string, without intervening  characters. If the utility receives an argument containing only the option, it shall behave as specified in its description for an omitted option-argument; it shall not treat the next argument (if any) as the option-argument for that option.

check if -f has bound default value.

duplicated.


multi-line comment warning

While compiling, I get a multi-line comment warning.
https://github.com/gipert/progressbar/blob/9fcfec70942227e733eea487b3ba79e13f59e207/progressbar.hpp#L26
I mean, it is not that big of a deal, but it's just not nice to get warnings while compiling. You can add a . in line 26 for example.

Thanks for reminding me about this. Fixed in 1425e0a.


Word Search Problem

@KhushbooNijhawan Please make sure you are giving PR in respective problem statement directory.
Thanks for contributing!


AssertionError: Arg new_tokens_idx must be a numpy array of dtype = int，，Can I run it on Wins?

Hi likai-1991,
We have updated the git with a fix for that error.
Can you pull the latest main version via
git pull
and retry ?
Wassim

Thank you,
I'll try again
------------------ 原始邮件 ------------------
发件人:                                                                                "WassimTenachi/PhySO"                                                                                @.>;
发送时间: 2023年3月16日(星期四) 中午11:10
@.>;
<EMAIL_ADDRESS>主题: Re: [WassimTenachi/PhySO] AssertionError: Arg new_tokens_idx must be a numpy array of dtype = int，，Can I run it on Wins? (Issue #6)
Hi likai-1991,
We have updated the git with a fix for that error.
Can you pull the latest main version via
git pull
and retry ?
Wassim
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

I have the same issue on Windows. The starts here.
When Running
benchmark.dummy_epoch(X, y, run_config)

AssertionError                            Traceback (most recent call last)
Cell In[49], line 1
----> 1 benchmark.dummy_epoch(X, y, run_config)
File e:\physo-main\physo\task\benchmark.py:61, in dummy_epoch(X, y, run_config)
46     actions = torch.multinomial(probs*prior, num_samples=1)[:, 0]                                              # (batch_size,)
47     #print("Choosing actions:\n", batch.library.lib_tokens[actions])
48
49     # # ---- Display ----
(...)
59
60     # ---- Appending actions ----
---> 61     batch.programs.append(actions)
63 # ---- Display ----
64 ax0.clear()
File e:\physo-main\physo\physym\program.py:729, in VectPrograms.append(self, new_tokens_idx, forbid_inconsistent_units)
726 # ------------------------------ Check new_tokens_idx ------------------------------
727 # Type
728 assert type(new_tokens_idx) == np.ndarray, "Arg new_tokens_idx must be a numpy array of dtype = int"
--> 729 assert new_tokens_idx.dtype == int, "Arg new_tokens_idx must be a numpy array of dtype = int"
731 # Shape
732 assert new_tokens_idx.shape == (self.batch_size,), "Arg new_tokens_idx must have shape = (batch_size,) = (%i,)"
733                                                    % self.batch_size
AssertionError: Arg new_tokens_idx must be a numpy array of dtype = int

It look like you don't have the latest version of the code where this issue was corrected.
Can you try to pull the latest version via these command at the root of the PhySO folder:
git stash
git pull
And then retry ?

I think I updated it. The error is in program.py and I figured it was updated recentely.

To check that you were able to properly update it can you check that line 729 of file program.py is now :
729 assert (new_tokens_idx.dtype == int or new_tokens_idx.dtype==np.dtype("int64")), "Arg new_tokens_idx must be a numpy array of dtype = int"

This is due to how numpy works on windows, see https://stackoverflow.com/questions/36278590/numpy-array-dtype-is-coming-as-int32-by-default-in-a-windows-10-64-bit-machine
This was corrected in the latest version of PhySO.


Share/unshare multiple directories at once

Currently we support this for the AsyncTerrainClient but not for the synchronous client. Both should provide identical support.

Clients APIs are identical as of afdc36d


plugin does not remove vehicles with entities inside

server version 1.20.4
purpurmc.
plugin version 1.3.0

oh there is a new option i didn't saw
  # Should we not perform actions on mobs that are mounted (e.g. a boat with a villager in it)?
      mounted: false

now it should work


Limit the maximum StyleBoxFlat shadow size to a reasonable value

This closes #41657.

How about solving this the right way, by clipping the contents of the preview?

@nathanfranke I don't see much of a point for allowing shadow sizes above 100 in the first place. As I pointed out in https://github.com/godotengine/godot/issues/41657#issuecomment-684032290, the shadow has an octogonal-like falloff making it look very strange with high radii.

Closing for now as there's no technical reason to prevent huge shadows, even if they don't look good.
If we want to add a hint for convenience, it should maybe be a bit higher and include ,or_greater to let users use extreme values if they feel like it.


Tweaking cache eviction policy to help with super large queries.

The new policy is like LRU, except we avoid admitting
a new item if it would mean evicting an item that has been accessed
in the last 60s.
The goal is to behave better on scan access patterns, without being as aggressive as
using a MRU strategy.
Closes #1714

That's the cache hit rate for a query where around half of the fast field fit in RAM.
Before the patch the cache hit rate is 0 for obvious reasons.


getFills: update typescript signature

There is noway how to specify product/orderId (which is supported by the API) for getFills() method because there is only PageArgs arguments type.

Fixed on master


Mistake in Example 1

Example 1 states " Get-ActiveSyncDeviceStatistics -Identity TonySmith "  This is incorrect as the -identity parameter is for the  not the user,   it should be  Get-ActiveSyncDeviceStatistics -mailbox TonySmith

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

ID: 3e9d90b2-695e-59b0-92c2-ab9bcf43a78e
Version Independent ID: 5647aff0-b7e9-a057-a63d-03b667a8c4b4
Content: Get-ActiveSyncDeviceStatistics (exchange)
Content Source: exchange/exchange-ps/exchange/devices/Get-ActiveSyncDeviceStatistics.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@m600ant Thanks for letting us know.
@chrisda Can you please confirm me so I can update this one?

Fixed

Thanks.
On Tue, Apr 17, 2018 at 2:00 AM, Chris Davis<EMAIL_ADDRESS>wrote:

Closed #759
https://github.com/MicrosoftDocs/office-docs-powershell/issues/759.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/office-docs-powershell/issues/759#event-1577169693,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ad_RZ_B4370VLe09GyflPbnXD-PbdLsoks5tpPhIgaJpZM4TWQ4z
.


Add support for proxy plugins

Allows creation of proxy plugins by name, type, and address in the daemon configuration. If multiple plugins are using the same address, containerd will only use a single grpc client conn for that address.

Codecov Report

Merging #2415 into master will decrease coverage by 0.27%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #2415      +/-   ##
==========================================
- Coverage   44.99%   44.72%   -0.28%
==========================================
  Files          92       92
  Lines        9398     9456      +58
==========================================
  Hits         4229     4229
- Misses       4486     4544      +58
  Partials      683      683

Flag
Coverage Δ

#linux
48.93% <0%> (-0.31%)
:arrow_down:

#windows
40.95% <0%> (-0.31%)
:arrow_down:

Impacted Files
Coverage Δ

services/server/config.go
0% <ø> (ø)
:arrow_up:

services/server/server.go
1.67% <0%> (-0.54%)
:arrow_down:

Continue to review full report at Codecov.

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

Hi,
just chinning in to say thanks for the PR, I believe I will find it very useful.
However it is possible to add also a few lines of documentation so that it is relatively simple to get started?
Cheers,

However it is possible to add also a few lines of documentation so that it is relatively simple to get started?

On creating a plugin or configuring it? Looks like we need to improve some of the documentation for configuration. For creating, do you think it would be helpful to put my example in contrib?

@dmcgowan Honestly I didn't have many problems in creating a plugin, like understand to create a grpc service and how to make it works.
What I still do not understand is how to configure it, supposing I have a service already running with the correct interface, how do I tell containerd to contact it?
As always, any, correct, up to date documentation is good documentation.

LGTM

Please, add few lines of documentation to this.


WIP: add false option to functions

fixes issue #479
I added the option to make logging false. I'm very unfamiliar with Pulumi so I hope this doesn't create more of a hassle than it solves.
I allowed args.logging to be false
then if args.logging is false then normalize logging returns early which then doesn't create a log group with makes loggingConfig false when creating function

@yyaskriloff Lambda will always create a log group for each function. Can you clarify what you are trying to do and share your use case?

My apologies I miss understood. I didn't know lambda automatically created a log group. I guess what I'm looking for is the ability to disable the cloudwatch logs by removing the access role from lambda as to not duplicate my logs if I'm using a third party for log monitoring.
In that case this PR can be closed because the code I wrote is far from accurate.
I thought that SST was just don't give you the option not to create not knowing that's the default.
Sending AWS lambda logs to Axiom

Would adding an explicit deny statement accomplish this?


Pathogen Nothing Happened

Hi. I installed via Pathogen, but I don't have any syntax hightlighting. Nothing happened...
Is there something else I need to do as well to get it to work??

Try using Minivimrc and check if it works, because it does when I tested it.


Upgrade socket.io to 2.4

Address CVE-2020-28481

Seems like Socket.IO 2.4.0 introduces some breaking changes: https://github.com/socketio/socket.io/releases/tag/2.4.0
Is there anything that might require updates in our code?

@hedasilv you are correct about 2.4.0, but the resolved version is 2.4.1 which reverted the breaking change from 2.4.0:
https://github.com/socketio/socket.io/releases/tag/2.4.1. That being said, 2.4.1 also undoes the security fix from 2.4.0 that this PR is trying to resolve, which makes this PR pointless.
For our use case, I don't think there is a viable way for us to enable strict domain allow/deny. I have work planned this phase to upgrade to socket.io v4, though, so I will have to address this directly then. For now, I think I'll lock the version to 2.4.0, and explicitly allow all origins via the suggested mechanism in the breaking change doc you linked.

Seems like Socket.IO 2.4.0 introduces some breaking changes: https://github.com/socketio/socket.io/releases/tag/2.4.0
Is there anything that might require updates in our code?

@hedasilv you are correct about 2.4.0, but the resolved version is 2.4.1 which reverted the breaking change from 2.4.0:
https://github.com/socketio/socket.io/releases/tag/2.4.1. That being said, 2.4.1 also undoes the security fix from 2.4.0 that this PR is trying to resolve, which makes this PR pointless.
For our use case, I don't think there is a viable way for us to enable strict domain allow/deny. I have work planned this phase to upgrade to socket.io v4, though, so I will have to address this directly then. For now, I think I'll lock the version to 2.4.0, and explicitly allow all origins via the suggested mechanism in the breaking change doc you linked.

Makes sense! Thanks for the detailed explanation and for taking care of this task!

This is great. We should plan to move to 4.x soon


New package: C-PartnerSystemhausGmbH.QuickFinder version 4.4.34

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Verify:

This app lives in the tray.


default route prefix to root

Currently the -web.route-prefix defaults to the path portion of -web.external-url. This makes it difficult for other components to communicate with the Prometheus API (for example Grafana), as it will need to know about the prefix, just for communication between the two applications. Load balancers and proxies have the ability and sometimes even default to rewriting request URLs to root anyways so it seems like a more sane choice to not prefix the API or in fact any HTTP endpoint.
My idea is that the -web.external-url is merely about user interaction as in, it is used for redirects, templating and for back-links in alerts.
While this is a small change, it is breaking so I am proposing to change this for the Prometheus 2.0 release.

Load balancers and proxies have the ability and sometimes even default to rewriting request URLs to root anyways so it seems like a more sane choice to not prefix the API or in fact any HTTP endpoint.

Some load balancers have that ability, not all.
I believe the current behaviour is correct.

This is about the default. And the current default does not seem like sane behavior to me FWIW. What's sane about every application having to know behind which LB it sits and what path prefix that LB has configured – and also being able to prefix it's internal route multiplexer? On top preventing sitting behind multiple LBs with different configs.

What's sane about every application having to know behind which LB it sits and what path prefix that LB has configured for it

That's a standard thing when you're prefixing, it only works otherwise for simple cases.

On top preventing sitting behind multiple LBs with different configs.

I don't think this is a sane setup for us to try and support.

It also comes down to Prometheus to Alertmanager communication, does it really make sense for Prometheus to fire alerts against /alertmanager/proxy/some/path/api/v1/alerts? That would be the logical consequence, as I think whatever we do should be consistent in the Alertmanager.

does it really make sense for Prometheus to fire alerts against /alertmanager/proxy/some/path/api/v1/alerts?

If that's what the user has setup via their proxies, then yes.

I don't think this is a sane setup for us to try and support.

Example, I expose my Prometheus servers publicly with locked down write endpoints behind mydomain.com/<prometheus-name>. Additionally, internally, I expose my Prometheus servers with <prometheus-name>.internal.com but with write endpoints enabled. Seems perfectly reasonable.

If that's what the user has setup via their proxies, then yes.

Yes, of course. That's why this discussion is about changing the default we chose for this flag to what I believe, is the sane choice.

Seems perfectly reasonable.

Not really. To do this in general the server would need to be aware of the different prefixes for the different domains so that it can use the correct prefix in responses.

That's a natural limitation, though I disagree that this means that setup won't happen frequently enough. But also it doesn't matter for the discussion.
Our thesis is: the sane behavior for an LB is to truncate the prefix when passing down a request. We would like to adjust the default to reflect that. This does not prevent anyone from doing it differently.
Taking the same problem to Alertmanager: Imagine Prometheus discovers AM pods in Kubernetes and wants to send them alerts via <pod-ip>:9093/api/v1/alerts. Why should that, by default, not work depending on whether or not those AMs are setup behind an ingress LB that provides access to them with a path prefix.
This internal alert traffic has nothing to do with how they are exposed. Consequentially, a sane setup does not leak the path prefix of the LB into the internal routing of the application.
That argument translates equally to Prometheus – also Prometheus and AM should obviously be consistent with their flag defaults.

Our thesis is: the sane behavior for an LB is to truncate the prefix when passing down a request.

I don't think that's a safe assumption. It's not the Apache default for example.

Why should that, by default, not work depending on whether or not those AMs are setup behind an ingress LB that provides access to them with a path prefix.

It may not work, because we have to choose some setup that won't work by default.

This internal alert traffic has nothing to do with how they are exposed.

There is no such thing as "internal" traffic, there is only traffic. If you make some endpoints disregard the prefix, then you break proxies that don't remove the prefix.

And the current default breaks everything because anyone communicating needs to know whatever LB might have been setup. There's absolutely such a thing as internal traffic. That's the very reason why in K8S for example, every pods gets its own IP, so we don't have to globally handle collisions on ports and paths and can decouple any ingress (i.e. external/user) traffic from how applications talk to each other.

From our perspective there's no such thing as internal traffic, there's http requests arriving at our endpoints and no way for us to tell what organisation specific semantics they have in terms of being internal/external (nor should they be).
Do you have examples of specific requests you believe it'd be sane to treat differently based on the http request?

This is not about treating anything differently. This is about changing a default flag value – nothing else. No mention of treating any traffic differently in any way at all.

I had missed that.
If we're going to be making a breaking change hear we should get an idea of how many users will break vs benefit.

IMHO most examples for apache and nginx don't rewrite paths, but both support it. Kubernetes proxy rewrites the path by default.
From a user standpoint, I think it's easier to understand the behavior if a flag's default value doesn't depend on the value of another flag.
I'm slightly in favor of this change, but I fear all the confused questions with this change. I guess we'll need to write a very good and detailed upgrade howto guide.

I came to report this as a bug. But after reading the comments I found out it could be fixed with the route-prefix luckily :-)
Background: My setup is Kubernetes which does URL rewriting by default. Also, in my previous nginx-load-balancer deployments I use upstreams and proxy_pass which also by default will implicitly rewrite to /. Prometheus is the only application I have run that has this default behaviour. Grafana, Kibana, Elasticsearch etc all works by default from the root route, and only uses external-url for prefixing URLs in served code. In my current deployment only the first gateway (Kubernetes Ingress load balancer) has knowledge about the actual client URL being used. So the second application-nginx-server which also proxies to Prometheus has no way of knowing the actual URL served to the client at any given time, and hence which sub-route to call Prometheus on.

I guess we missed the chance to change the flag behavior. @brancz shall we close this one?

I've been wanting to write some user-guides on how to use the respective flags in different situations. Once we have that the situation should already be a lot better. I'm fine with closing this.

@StianOvrevage @brancz Until those guides are in place, what is the recommended combination of flags for k8s and web.external-url/web.route-prefix?
My use case, and what I believe you were discussing as well, is having Prometheus primarily served (through an ingress) at https://some-domain/prometheus. I've set -web.external-url=https://my-domain/prometheus -web.route-prefix=/, in combination with ingress.kubernetes.io/rewrite-target: "/" on my ingress. This seems to work, and doesn't break the /metrics endpoint which it initially did...
However, if I access prometheus directly instead of through the ingress, I cannot get it to work. I'm not sure if this is a common use-case? Our developers run a lot of minikube, and typically don't use ingresses, but rather just use the NodePort. For this, neither /prometheus nor / work. Is it possible to support this in parallell with the above?

That is the currently expected behavior. What alertmanager actually does is ensure, that the loaded URL ends with a slash and redirect if it doesn’t. From there on onwards, it only performs requests relative to that path, which is why even after rewriting the URL everything works perfectly, however because it’s just a relative request, this continues to work with nodeport/port-forward. Not sure whether adopting this behavior in Prometheus would be considered breaking, but I think it would be an great UX improvement.


HMD Locomotion is Missing

Need to port to C++. Maybe integrate into one VR Pawn, or use inheritance or composition?

I should do simpler Input bindings with this one so both examples are present...

Completed.
https://github.com/sclark39/UE-VR-Code-Sample/commit/a5554141ba540c6dc91c29ab5406a2e803a56fea


Select a valid choice. that choice is not one of the available only when replacing a field

Hello. I already searched on the old posts but i don't find a solution for my problem.
I have the next model  :
In views.py :
class TermAutocomplete(autocomplete.Select2QuerySetView):
    def get_queryset(self):
        # Don't forget to filter out results depending on the visitor !

        qs = Term.objects.all()

        if self.q:
            qs = qs.filter(nom__startswith=self.q)

        return qs

In forms.py
class TermForm(forms.ModelForm):
    class Meta:
        model = Term
        fields = ('__all__')

    subterms = forms.ModelChoiceField(
        queryset=Term.objects.all(),
        widget=autocomplete.ModelSelect2Multiple(url='term-autocomplete')
    )

and in views.py, my controller
def term_new(request):

    if request.method == "POST":
        form = TermForm(request.POST)
        if form.is_valid():
            term = form.save(commit=False)
            return redirect('term_new', pk=term.pk)
        else:
            form = TermForm()

    return render(request, 'term_edit.html', {'form': form})

And my model
class Term(models.Model):
    nom = models.CharField(max_length=255, verbose_name="Nom du term", db_index=True)
    langue = models.CharField(max_length=100, verbose_name="Langue", choices=TYPE_LANG)
    lemma = models.CharField(max_length=255, verbose_name="Lemma du term", db_index=True)
    subterms = models.ManyToManyField("self", verbose_name="Subterms", blank=True)

When i try to create a new Term, i get the following error :
"select a valid choice. that choice is not one of the available"
But when i change my form using the widgets parameter (without replacing the field), it works :
class TermForm(forms.ModelForm):
    class Meta:
        model = Term
        fields = ('__all__')
        widgets = {
            'subterms': autocomplete.ModelSelect2Multiple(url='term-autocomplete'),
        }

Do you have some idea about what's happening with my code? Actually, i'm not able to replace the field and i need it to add custom validators.
On the other hand, when i try to edit a Term (replacing field code), i get an "invalid int 10" error. But when i use the widgets attribute without replacing the field, i can edit, everything works very fine.
Thank you in advance

Select a valid choice is because your choice pk is not found in the form field queryset.
Did you try:
subterms = forms.ModelMultipleChoiceField

Instead of:
subterms = forms.ModelChoiceField

For your ManyToManyField and ModelSelect2Multiple widget ?
Sounds like it might work better together.

You're right!! Thank you so much! I was using the wrong widget for a M2M relationship


Incorrect documentation about Bundle.asUInt

The documentation of Data.asUInt states:
/*
 * @note Aggregates are recursively packed with the first element appearing
 * in the least-significant bits of the result.
 */

The actual behavior is the other way around, the first element is put in the most significant bits. This is also documented in an Example:
class Bundle2UInt extends CookbookTester(1) {
  // Example
  class MyBundle extends Bundle {
    val foo = UInt(4.W)
    val bar = UInt(4.W)
  }
  val bundle = Wire(new MyBundle)
  bundle.foo := 0xc.U
  bundle.bar := 0x3.U
  val uint = bundle.asUInt
  printf(p"$uint") // 195

  // Test
  assert(uint === 0xc3.U)
}

In this code, the first element is foo, which value 0xC followed by bar with value 0x3. The resulting packed UInt is 0xC3, with the value of foo appearing in the MSBs.

The documentation is actually correct. What is missing though, is that Bundles store their elements in reverse order from what you might be expecting. bar is the "first" element for the Bundle. This should be called out in the documentation for Bundle though, I will add it shortly.


Signal/CyberGhost/Others crashing on version 0.2.4-55-g4c4086a [OmniRom] [7.1.1] [LogCat Inside]

Hey, Im running a Nexus 6P with OmniRom (Android 7.1.1) and I had MicroG version 0.2.4 stable. Everything seemed to work fine, but I would always get messages from apps to "update google play services".
I updated microG to version 0.2.4-55-g4c4086a and now the messages are gone, but some apps crash as soon as I open them. Signal, CyberGhost VPN, and a few others (Such as ZPN Connect) are unusable, and only work if I downgrade.
I have checked all permissions, Signature Spoofing permission is granted, and I even tested with "Push Notification Tester" to make sure GCM was working. This only seems to happen with microG preview releases.
Is this something I have configured wrong?
Thanks

You may need to reinstall the apps for them to register correctly.

Yeah I tried that with CyberGhost to no avail. I will try again and report back now.

Just updated microg to the latest again, uninstalled all the problematic apps (cyberghost, zpn, signal) rebooted and reinstalled the apps. Signal now works, ZPN and cyberghost still crash for some reason. Is this some kind of problem with the new microG?

@cswag: It would help if you post a logcat.

Do I need root? I don't have root on my device at the moment

If anyone else is also running the latest microG, maybe try installing CyberGhost from the play store and see if it crashes too? I'm not sure if this is just me

@cswag: No, it doesn't need root.

I will try to get a LogCat shortly.

Im not sure if this is exactly what you need. If not, please let me know: http://pastebin.com/ED6WJYGS

I dont understand why the old version of microG works fine, while the new one fails.

Both apps seem to make use of the Firebase API, which is not yet supported by microG. It was "working" before, because it refused using microG and thus did not call the code that leads to crash now.

Thanks for the explanation. Would there be any kind of workaround other than downgrading? It would be nice if this worked.

I have not tested it but you may want to try blocking their Firebase related components (either using an app like MyAndroidTools or manually with pm disable).

I see, thanks :)

@cswag This should be fixed as of 0.2.4-62 preview, can you verify it?

Just tested, everything works great on 0.2.4-62
Thanks :)

I'm sorry to reopen this thread, but how do I get 0.2.4-62 preview version ? I've installed 0.2.4 and I'm getting the same issues described above and i gotta fix it as well.
Thank you

If you are using f-droid then select the option in its settings for unstable updates.
If not then you can download: from https://microg.org/download.html
The current preview build is 0.2.4-92

Or (in F-Droid case), just go the package view and select the correct version. Unstable updates can bring you unstable updates of other packages, I’ve lost messages in another app because of that.

Thank you, i've managed to install it and now Signal is working. It's not able to find any contacts on my phone even with permissions granted, but better than crashes.
Thanks guys


Modified the README.md

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #80
Type of change
Please delete options that are not relevant and insert x in the box to check the box.

[X] This change requires a documentation update

Test Configuration:

Firmware version:
Hardware:
Toolchain:
SDK:

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] Any dependent changes have been merged and published in downstream modules

@garimasingh128 , please review this PR

@garimasingh128 , please review this PR

Looks neat

Looks neat


Think twice before giving feedback to this community! WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWThink twice before giving feedback to this community! WWWWWWWWWWWWWWWWWWWWWWWWWWThink twice before giving feedback to this community! WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWThink twice before giving feedback to this community! WWWWWWWWWWWWWWWWWWWWWWWWWW

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Issue description:

Steps to reproduce:
Link to minimal example project:

i want to kill myself

do you recommend any method? i want it to be quick and painless

please help me

im so sorry


ViperIt unable to compile with Xcode 13

class HostingUserInterface - file UserInterface+SwiftUI.swift line 16
Incorrect argument labels in call (have 'nibName:bundle:', expected 'coder:rootView:')

Hi @Speakus ,
thanks for reaching out. Let's wait for the golden master release of Xcode 13. I'll keep an eye on it.
Cheers.

I was able to reproduce it with Xcode 13 RC version. Working on a solution, thanks 👍

Fixed on #131

Published new version v1.5.0 with the fix 👍


Fix for changing orientation.

This accounts for the case of mounting a component in one orientation (i.e. landscape) and then changing to portrait. Without this change the spinner will be off center in the case where it is originally mounted in one orientation and then changed.

Thank you very much for your pull request. Now the new version of this package has been updated.


Wayland support

Are there any planes for Wayland support?

Currently the only backend is fltk, I think it already supports wayland with some tweaks. So yes I guess that should be possible. I am building a new native gtk3 backend, but I don't know what it would take to get that working on wayland (I am not a linux developer)

Currently the only backend is fltk, I think fltk already supports wayland with some tweaks. So yes I guess that should be possible. I am building a new native gtk3 backend, but I don't know what it would take to get that working on wayland (I am not a linux developer)

Good to know, why gtk3 and not gtk4?

No particular reason other than I had some examples already of using gtk3 in rust, I guess I could look at gtk4.

Fair, just make sure you use gtk3/4 without adwaita as that has lower compatibility.


Support ARM platform

crutkas: taking over the body here for creating the work items
Can do now work:

[x] Upgrade everything to .NET Core/Standard away from .NET Fx. <- https://github.com/microsoft/PowerToys/issues/776
[x] Eliminate all dependencies that are .NET Fx only. <- https://github.com/microsoft/PowerToys/issues/8557
[x] Upgrade everything to .NET 5 <- #8650
[ ] Runner: the exception handler is relying on x64-specific registers
[ ] Update installer to verify proper processor type for installer

don't do ARM installer for x64 user
don't do x64 installer for ARM user

Pure ARM64 solution

[x] WPF ARM64 support <- https://github.com/dotnet/wpf/issues/1817
[ ] WinForms ARM64 support
[ ] Installer updates
[ ] Get CI to ARM64 solution
[ ] Get Build farm to ARM64

Hybrid solution work (ARM64 where possible, everything else is x86)

[ ] Get solution to work E2E on x86
[ ] Update installer to verify proper processor type for installer

warn do x86 installer for x64 user

[ ] Get solution to work in hybrid ARM64/x86

Should update the readme with this until we have time to address it.

Readme calls this out

Thank you. Lack of ARM64 support seemed like an oversight considering the Surface X product announcement.

We have an internal build that can do this. We are aware of the device and the need to get a build out with ARM support. Just takes time and prioritization for what gets worked on. Great example of a thing people can vote on to get us to up the priority.

https://github.com/microsoft/PowerToys/issues/413 is a prerequisite for this issue.

Thanks for the update folks.

Looking forward to Power Toys on SPX!!

are you looking for Arm beta testers for the internal build? because I would LOVE to volunteer (hint hint!)

@marypcbuk, when a non-POC stable build happens, you'll be one of the first (after me :))

I have also committed myself to an ARM based Tablet / Laptop, alas no the Surface Pro X as yet, I am running the Samsung GalaxyBook2. Since Chromium Edge delivered a production build for ARM64 - there hasn't been much I could not do on my GalaxyBook2. Although the 4gb of RAM and 128gb Storage is a limitation. I'd love to think I could have a Surface Pro X with 16gb RAM and at least 256gb SSD (or even 512gb) by year's end, but the current AUD to USD exchange rate is making that increasingly unlikely.

@bpm-masters we will support ARM

@bpm-masters we will support ARM

Very much looking forward to this for my SPX! I will also throw my hat in the ring if testers are needed.

I don't know if testers are needed, but if they are, hi 👋

Also would like to be notified once this is available for evaluation, as I'm on an SPX.

Me too - I chose a Pro X over a Pro 7 foolishly believing it would be the wave of the future. I can live without Facebook Messenger (x64-only- whyyyyyy?) but not PowerTools. But x86 would work too.

Me too - I chose a Pro X over a Pro 7 foolishly believing it would be the wave of the future. I can live without Facebook Messenger (x64-only- whyyyyyy?) but not PowerTools. But x86 would work too.

Give us time :)

Take your time. Brice Lamson still has the x86 image resizer :-)

I'm very much looking forward to PowerToys on ARM! It's the one major thing I'm missing on my Surface Pro X, and I desperately miss it. :(

Another SPX owner, who’d love to test this if it was available.

Same here, the only thing I am missing on my SPX is PowerToys.

I love PowerToys on my SB2 and I'm excited for it on aarch64 for the SPX. I will wait however long it takes because I know you guys are awesome and working on it and when it comes out it will be amazing!

Adding to the Choir, really looking forward to this for my Pro X

Any way the community can assist?

Another SPX user desperately waiting to see this happen for many months now - if the ARM user base is too small to consider, please say so and we can go with another alternative.

Another SPX user desperately waiting to see this happen for many months now - if the ARM user base is too small to consider, please say so and we can go with another alternative.

There are existing alternatives? 😅

Another SPX user desperately waiting to see this happen for many months now - if the ARM user base is too small to consider, please say so and we can go with another alternative.

There are existing alternatives? 😅

Many individual products exist as alternatives - potentially alternative paths to port to ARM, should exist, too.
Would you suggest there're no alternatives to any functionality provided?

Another SPX user desperately waiting to see this happen for many months now - if the ARM user base is too small to consider, please say so and we can go with another alternative.

There are existing alternatives? 😅

Many individual products exist as alternatives - potentially alternative paths to port to ARM, should exist, too.
Would you suggest there're no alternatives to any functionality provided?

I think there is no other program with combines so many functions like powertoys. Don't wan't to install 10 programs to have the same functionality as with powertoys.

Any update / visibility on arm64 support for PowerToys?
Microsoft has not only released Chromium Edge but more recently VS Code (now in stable as well) and powertoys is really one of the last needed pieces of the puzzle to make the SPX the perfect device

Any update on PowerToys on ARM64? I would really like to start using it on my SPX, really great device, just think Microsoft dropped the ball on marketing this device, it's much better than I could have imagined, I'm glad I sold my Surface Pro (2017) for this.

Joining the (hopefully not small) group of windows on arm users who would love to see power toy on arm. I am using a Samsung Galacy Book S and love it, but I really miss power toys. Any chance we see it in the near future?

I've heard that they have an internal build that works on arm64, so hopefully they release it soon.
I would be happy with a pre pre pre alpha version too. xD
@sozialpr

@McBaumwolle  I would gladly be an alhpa or beta tester for this. :)

I've heard that they have an internal build that works on arm64, so hopefully they release it soon.

The internal build was a one off by the WinOnArm team to verify it would work and how well, we still have a ton of infra work to support this.

Talking with a few folks, we may need to do x86 support to then support this as there are parts that will have to be x86 emulated without .NET ARM64 for desktop apps not done yet.  By doing x86, we can validate that all x86 is stable before we do the mix mode ARM.

@crutkas does the upcoming X64 emulation on WoA make things any easier?

Shame this thing has a .NET dependency and is not just c++
Get Outlook for iOShttps://aka.ms/o0ukef

From: marypcbuk<EMAIL_ADDRESS>Sent: Wednesday, September 30, 2020 2:09:36 PM
To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: James Clarke<EMAIL_ADDRESS>Manual<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] Support ARM platform (#490)
@crutkashttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrutkas&data=02|01||48ecc14f8df34ac57b8108d86585231d|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637370969770893664&sdata=hsQy%2Fx%2FenIt1oeStkoX%2B9y%2FVzL4D72NskUCasaXkf1s%3D&reserved=0 does the upcoming X64 emulation on WoA make things any easier?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPowerToys%2Fissues%2F490%23issuecomment-701647423&data=02|01||48ecc14f8df34ac57b8108d86585231d|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637370969770903655&sdata=vkNM%2BS0COZ%2BdAadfZewllWhBC%2F3Z0f6IEj0xy1ArnQc%3D&reserved=0, or unsubscribehttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAITOOWJTLZQ4IYOGAJ22Z3SIONBBANCNFSM4I7DJQIA&data=02|01||48ecc14f8df34ac57b8108d86585231d|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637370969770913652&sdata=RV7rF8%2FwiPObXBi4Z1X0VbKhMmyQ3xfmFT%2FMLIUbVT8%3D&reserved=0.

@clarkezone you signing up to help port everything?

@marypcbuk In some ways  yes but others no.

I'm taking over the top for work items.

SPX user here waiting for news or alternative lol

So excited for PowerToys on ARM, it's the only thing I'm really missing on my SPX. Any release date yet?

we need https://github.com/dotnet/wpf/issues/1817 as well

It would be really cool, if you could implement ARM64 support because there are many PCs which use ARM instead of x86.

WPF ARM64 support has arrived!
https://devblogs.microsoft.com/dotnet/net-july-2021/#windows-arm64

crutkas: taking over the body here for creating the work items
Can do now work:

[x] Upgrade everything to .NET Core/Standard away from .NET Fx. <- https://github.com/microsoft/PowerToys/issues/776

[ ] Eliminate all dependencies that are .NET Fx only. <- https://github.com/microsoft/PowerToys/issues/8557

[ ] Upgrade everything to .NET 5 <- #8650

[ ] Runner: the exception handler is relying on x64-specific registers

[ ] Update installer to verify proper processor type for installer

don't do ARM installer for x64 user

don't do x64 installer for ARM user

Pure ARM64 solution

[ ] WPF ARM64 support <- https://github.com/dotnet/wpf/issues/1817

[ ] WinForms ARM64 support

[ ] Installer updates

[ ] Get CI to ARM64 solution

[ ] Get Build farm to ARM64

Hybrid solution work (ARM64 where possible, everything else is x86)

[ ] Get solution to work E2E on x86

[ ] Update installer to verify proper processor type for installer

warn do x86 installer for x64 user

[ ] Get solution to work in hybrid ARM64/x86

WPF ARM64 support
WinForms ARM64 support
both have been supported alrready

Windows 11 has x64 emulation. Runs smoothly. I think this can be closed

Windows 11 has x64 emulation. Runs smoothly. I think this can be closed

That's bullshit, please don't write something like this in this thread

Windows 11 has x64 emulation. Runs smoothly. I think this can be closed

@libewa that's not very helpful - or necessary since the last dependency is identified and in progress

We have an internal build that can do this.

Just out of interest, how did you create a build for arm when wpf support for arm64 wasn't available, and xaml islands only supports .net core 3.1

That was before when we had only two c++ based projects.
We tried out WinUI 3 for settings and now are waiting for elevation support.  Once that comes in … fingers crossed :)

Need Help

@Happykr2 right now, We are working on upgrading everything to .net 5 (then to 6). If you want to help there, pop over to that issue (on our roadmap)
we then are in a holding pattern for WinUI 3 to add elevation and multi window. Hope is soon for those features.

With this DynamicDependencies: support elevation PR being merged, Now All of WinAppSDK (that includes WinUI 3) both Packaged or Unpackaged Apps should be ready for supporting Elevation.  wait for the next release. (i.e v1.1)
according to WinAppSDK roadmap WinUI 3's multi top level window support is also planned for v1.1

@crutkas  - I can take on the "Runner: the exception handler is relying on x64-specific registers" portion of this.
Also, anything involving changes to the solutions, props, projs I can take on.

Email me and let’s sync. Big blocker no matter need to upgrade settings.

@jaimecbernardo @snickler & co; after recent pr's, (also thinking of winui3, but that's less related) I'm wondering what all this will do with the installer file size. Can you tell already at this point? Would it make sense to create one installer file for x64 and one for ARM? What would be the difference?

Presumably this means ARM64 support is coming with the 0.58 release?

Winui3 will make it bigger. The idea for arm64 is that it'd be a different installer at first.

Presumably this means ARM64 support is coming with the 0.58 release?

Not for 0.58.

@snickler @jaimecbernardo @yuyoyuppe Did someone ever test the preview handlers on arm64? From my experience prevhost makes problems on every corner, so I wouldn't be surprised if it didn't work.

@Aaron-Junker testing it right now, and they indeed do not work :)

@snickler @jaimecbernardo @yuyoyuppe Did someone ever test the preview handlers on arm64? From my experience prevhost makes problems on every corner, so I wouldn't be surprised if it didn't work.

I don't think we've gotten the preview handlers working yet, but I'm sure we'll be able to figure it out 😎.

@Aaron-Junker testing it right now, and they indeed do not work :)

Sadly what I expected. So the registry key name (under shellex) for 32-bit handlers is diffrent then the one for 64-bit ones. So maybe there is another one for arm64.

Hey everyone, we've shipped ARM64 build of PowerToys :) Enjoy
https://aka.ms/installpowertoys

note: if you have the x64 build already installed on your ARM device, you will have to uninstall it before installing the ARM64 version

Sweet thanksgiving
On Tue, Jun 7, 2022 at 7:17 PM Clint Rutkas @.***>
wrote:

Hey everyone, we've shipped ARM64 build of PowerToys :) Enjoy
https://aka.ms/installpowertoys
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/490#issuecomment-1149262391,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK7GOSEOOUOOF4VXXX7XUULVN7KA7ANCNFSM4I7DJQIA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Dave W. Shanahan
@.***
(781)405-1859

Hey everyone, we've shipped ARM64 build of PowerToys :) Enjoy
so glad to see it! thanks

A joyous day this is!


use jenkins 2.426.3

before 2.426.x the prototype.js library that was included in core caused problems with the generated json in some cases. By using LTS version 2.426.3 the problems no longer occur
fixes #23

Testing done
manual testing

### Submitter checklist
- [x] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!
- [x] Ensure that the pull request title represents the desired changelog entry
- [x] Please describe what you did
- [x] Link to relevant issues in GitHub or Jira
- [ ] Link to relevant pull requests, esp. upstream and downstream changes
- [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

I have some misgivings on being on last LTS.  Unfortunately, many organizations don't keep up to date...


Migration to Craft.js

Craft.js is another page-builder framework like Grapes.js (which destack currently uses)
However, Grapes.js isn't the best fit for this project.
1. TypeScript support
Fully typing Destack isn't possible yet because Grapes.js doesn't have any (working) TypeScript support yet. There has been a community effort before, but it seems to be abandoned for now.
Craft.js has TypeScript definitions embedded in it.
2. Grapes.js wasn't made to be used with react, unlike Craft.js.
Craft.js was made to be used with react, which means maintaining the project will be easier for the future.
3. Craft.js already has a system to store the component state.
The basic example includes a feature to copy the (compressed) state to clipboard. This will make it easier to do what destack does now ( parsing the default.json, etc ).
Here's a quick guide: link
This issue exists for discussion on the topic, and for tracking the feature.

Any update on this? I would like to contribute to migrating to craft.js. This project is severely limited in scope from grapejs.

@jpetrantoni
There's significant work done in feature/craftjs. It's my main focus now regarding the project.
I'd try to get a complete status on a PR in a few days. Quick summary for now:

MVP is now at a working in the feature branch
Editor is a bit slow to load (reason is Next.js transpiles the editor react code in production)
Some themes are not yet checked if they work properly (Hyper UI is but Tailblocks and Meraki UI are not)
We'd need e2e tests that works with Craft.js

If you are looking to contribute you can have a look at feature/craftjs. Some things that might be helpful are e2e tests and maybe having a quick check with Tailblocks and Meraki UI components.

There's a new starter project for Destack v2 (with Craft.js) at destack-starter-beta for anyone looking to have a peak.
You can get it locally by:
git clone https://github.com/liveduo/destack-starter-beta

The Craft.js project hasn't been updated since August. Are you certain it's still active?

@brunonar Quite late response but it's for everyone's visibility.
There's a PR on 7/12 from @prevwong. Yet, I'm not certain Craft.js will remain active. Many projects including Craft.js(AFAIK) are maintained by a single engineer. That means he might go offline for a while as stuff happen.
But, Craft.js ticks all the boxes mentioned by @iojcde in this issue. It also adopted by quite a few people and there's a fair chance another maintainer comes by or someone's forks the project off.
Moving forward, I think it will be aright whatever the case. Besides, Craft.js unlike Grapes.js is a thiner layer that manages the viewport and component state (redo/undo, serialisation etc) and it easier to replace or replicate if needed.


Suggestions #0

Colored printing
Print 'Hello ' + user_input + '!'
Showing a C-level version too (C = 'portable assembly')
Basic calculator (+,-,*,/)
Random number generator
All other projects with NCurses-like TUI (maybe no assembly)
IPC (as coprocesses)
File I/O

nice ideas. i do not have the time to do the c stuff. i will try an rng in asm.


METRON-2078: Remove Storm dependency from metron-writer

Contributor Comments
This PR is a first attempt at refactoring Storm dependencies out of metron-writer.  Everything builds and all tests are passing.  We have been using these test instructions to validate module refactor pull requests in full dev.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:

[x] Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
[x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

[x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?

[x] Have you included steps or a guide to how the change may be verified and tested manually?

[x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
mvn -q clean integration-test install && dev-utilities/build-utils/verify_licenses.sh

[x] Have you written or updated unit tests and or integration tests to verify your changes?

[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[ ] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:
cd site-book
mvn site

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

+1 Pending the manual tests that you referenced. This looks solid and straight forward.  Nice work.
I was able to validate the end-to-end flow of alerts, along with the Profiler in Storm, Spark and the REPL.  If you can confirm validation of the other items, let's ship this.

Manual tests passed.  Going to merge now.


tab for list.focusDown command works not like DownArrow

VS Code Version:
Version: 1.55.2 (system setup)
Commit: 3c4e3df9e89829dce27b7b5c24508306b151f30d
Date: 2021-04-13T09:35:57.887Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS Version:
OS: Windows_NT x64 10.0.19042

Expected:
With tab bound to list.focusDown, my expectation was, that navigation behaves exactly like DownArrow with the same command.
Behaviour:
Tab navigates a line down. Tab again then focuses the quick fix icon in the list and does not select the next entry.
On fast tab presses or holding tab, the navigation stops completely (randomly).
Steps to Reproduce:

Create the following keybinding:   {
"key": "tab",
"command": "list.focusDown",
"when": "listFocus && !inputFocus"
}
Install a lsp for e.g. markdown
Create multiple problems in two files which can be quick fixed
Focus the first problem in the list of your problems panel
Expand all problems

Hit tab to navigate through your problems

Navigation gets stuck randomly while holding tab

Does this issue occur when all extensions are disabled?: Yes/No
This is not possible, because without lsp support, no quick fixes are available. I replicated the behaviour with all extensions disabled and two different lsp (markdownlint & rust analyzer), one activated at a time.

Due to accessibility features, Tab is a special key and I would avoid assigning it to commands. Closing this as a scenario which we can't support. cc @isidorn

Yup, makes sense to not assign commands to tab

hi,
dont want to reopen it. Just for further clarification: Why is it even possible to assign tab for commands?
king regards


Update at Avalonia 11.0.4

We should not update the dependency version unless we really need new features from the new version.
Otherwise, it will unnecessarily force everybody to a new version.


Update arabic theme-search-algolia.json

Complete translation file to arabic

Pre-flight checklist

[ ] I have read the Contributing Guidelines on pull requests.
[ ] If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
[ ] If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Test Plan

Test links

Deploy preview: https://deploy-preview-_____--docusaurus-2.netlify.app/
Related issues/PRs

Thanks @abuda7m
Can you please sign the Facebook CLA?
I can't merge your PR without it.
https://github.com/facebook/docusaurus/pull/9626#issuecomment-1849719596

Unfortunately I can't merge this PR so let's close.
Feel free to sign the CLA and I'll reopen


Upgrade to cabal-<IP_ADDRESS>

We will upgrade to cabal-<IP_ADDRESS> instead in https://github.com/input-output-hk/cardano-node/pull/3334


gfmpw-1 dv issues

I tried to setup dv testbenches for gfmpw-1c tag accordingly to mpw-* (after fixing pin assignments) tests and found two issues:

There is a problem with interacting with simple_por on caravel. Changing VDD pin state in verilog testbech doesn't change its state inside caravel module (where this signal is happens to be a constant 1). This causes simple_por to keep waiting for @(posedge VDD) forever and keep resetting caravel. Simple workaround for this problem is to change @(posedge VDD)  to some constant delay.

More problematic issue is that caravel turns its wb_rst_i pin to undefined state (and all other pins few cycles later) at fixed time of around ~700us (with 12.5ns clock) into testbench. This time doesn't depend on any external event or interaction with design. I found that it shifts in time only when instruction count of caravel .c program changes - so it probably is some internal caravel problem. It breaks even on default user_proj_example design (without la interactions, only output pins). The only thing that I do in .c file is setting gpio pin modes. I tried to trace this signal, but could not found the reason for this behavior. I can provide more details if needed. This problem is critical, because it breaks possibility of testing larger designs, where shorter tests are not possible. What's important - this problem only happens on GL level, on RTL everything works fine.

Second problem will be fixed with PR https://github.com/efabless/caravel_mgmt_soc_litex/pull/133


Inconsistency between Rosetta and Filfox - Investigate

As posted by @qiwu7

@jleni can we reopen this? The second issue I reported is not resolved.
the transaction_identifier.hsh is inconsistent with block explorer. Not sure which one is correct and which is not. /block endpoint shows bafy2bzaceazqvy2eudmkvch4noyzqdj55k65phxsstbemitzisw7diqqjw324 whereas block explorer shows bafy2bzaceasogrhjxosqmdjyp6lcfhiu2eg24twfszhmvrslg7hesc3ozkrmi.

Based on https://github.com/Zondax/rosetta-filecoin-proxy/issues/77#issuecomment-707508058

We should involve someone from Lotus to clarify if is there any difference between on getting the message's CID from:
(assuming that they both correspond to the same transaction)
CID1 from: StateCompute: output.Trace[0].Msg.Cid().String()
CID2 from: ChainGetParentMessages: messages[0].Cid.String()

Is CID1 the receipt CID and CID2 the original CID of the message?

I guess not because receipt has its own field on the struct and I'm accessing to the (original?) message
https://github.com/filecoin-project/lotus/blob/1a70dbe37d1ec080a0b39f141bbd06a5cba89892/api/api_full.go#L738

So this is because there are two message types: Message and SignedMessage that we often have to conflate when talking about messages. The difference is solely that SignedMessage includes a signature field.
The ChainGetParentMessages output is giving you the SignedMessage CID, which includes the siggy. This appears to be what filfox displays as well. The output from StateCompute is the unsigned message, which naturally has a different CID.
For internal consistency, I would recommend always using the unsigned message CID, which you can get from the ChainGetParentMessages output as messages[0].Message.Cid().
We might wanna consider changing ChainGetParentMessages to return the unsigned message CID, but the larger problem of "urgh, we have 2 different ways (and so different CIDs) to think of a message" is...unfortunate.

So this is because there are two message types: Message and SignedMessage that we often have to conflate when talking about messages. The difference is solely that SignedMessage includes a signature field.
The ChainGetParentMessages output is giving you the SignedMessage CID, which includes the siggy. This appears to be what filfox displays as well. The output from StateCompute is the unsigned message, which naturally has a different CID.
The "canonical" message CID is always the SignedMessage CID, but the VM doesn't see that (and so the InvocResult object is currently giving you the unsigned message CID). I can probably change the InvocResult struct a bit to have the canonical CID instead.
One minor point: This is only a difference observable in Secp messages. BLS messages are identical in their signed and unsigned versions (since the siggy gets aggregated with all other BLS siggys).

The "canonical" message CID is always the SignedMessage CID, but the VM doesn't see that (and so the InvocResult object is currently giving you the unsigned message CID). I can probably change the InvocResult struct a bit to have the canonical CID instead.

Yeah it will be great if we are consistent here 👍


Categories Grouping

Creating of a module to do category grouping during the Modelling Phase. Grouping should be a manual decision made from users


Eslint does not reload dependencies after installing a new package ('X' should be listed in the project's dependencies)

I remotely connect vscode projects via ssh (Ubuntu server) and I know this wasn't happened before.

opened existing project via ssh (eslint extension is installed into both local and server sides)
installed a new package.
imported package.

This error message showed:
'http-status-codes' should be listed in the project's dependencies. Run 'npm i -S http-status-codes' to add it

When I disconnect and connect again, this error message is gone.

This is so annoying because I have to reconnect whenever I install a new package.
Is there a way to fix this? or Is this a bug???

This is very hard to fix since ESLint doesn't offer any API to find out when a file should be validated, especially when a file A depends on an external dependency D.
The next version of ESLint extension (available as a pre-release already) has two ways to improve this:

files will be validated on focus gain
a command to re-validate all open files

This will avoid that you need to reconnect to the server.
I will close the issue since without new API from ESLint there is little I can do to make this correct in all cases.

This happens to me locally, with no SSH involved. To reiterate, the issue is:

Open up vscode on existing project.
Open up a file that is linted by eslint.
Add a new dependency (ex: npm install --save tmp).
Return to vscode and add import * as tmp from 'tmp'
vscode eslint complains that the tmp doesn't exist as a dependency.

The only resolution is to restart the Eslint server, which is effectively what  hongz1  is doing by re-connecting via SSH.

This is very hard to fix since ESLint doesn't offer any API to find out when a file should be validated, especially when a file A depends on an external dependency D.

@dbaeumer I don't see how this is related --- It seems to me that the problem is simply that the VSCode ESLint server should know to restart itself when the dependencies in a package.json have been modified?  This is essentially what we are having to do right now.


Image capture color modes

Image capture could feature multiple color modes (like smartphone cameras have). Mode should be an ImageCaptureOption Examples could be:

Grayscale
Normal color (like it is now)
HDR (more vibrant)

Still needs some thinking. It could also be left up to the implementation outside the library

I have an additional suggestion for color mode:
You could have, more broadly, output modes.
This can include Normal, Grayscale, HDR, Rec709, LINEAR, LUT (the simple obs kind), etc...
But I propose that in additon to normal color mode output that there be a raw blocktype output. This would output an array of block material hits as the pixels attached to some metadata for capture resolution.
Reasoning:

This would allow a user to perform any color processing they want on the output after, with the ability to quickly change block color pallets.
With this intermediary output before color processing as output, a plugin developer could set up a system which renders these blocks onto a canvas in the world made up of the exact blocks they are trying to depict. This would have much nicer and cooler results than translating from block to color and back again I imagine.

Implementing this would be a matter of storing blocktype upon hit, and putting off color processing to a later stage at which it will run a different color processing step based on which enum is selected. Or maybe instead of an enum it's a matter of which overloaded image.process() function you call after capture to get the final desired output. In that case, you would first render the image, at which point you can access the raw block types array from the raytrace. Then you can call one of the process functions to get the desired image output type.
// an enum for it would look like this
public enum ImageProcessMode {
    NORMAL,
    GRAYSCALE,
    HDR,
    RAW // block type output
}

as for file output, raw type could be serialzed to json with GSON. But thats for other plugin devs to worry about unless you want this plugin to output files also.


Staging LC picks up PFS's from the disjoint RSBs at random

Thanks for filing a bug report :-)
Steps to Reproduce
Environment setup:
node1(LC) <----> hub(python client) <------> node2 (LC)

establish bi-directonal channels between node1 and hub, node2 and hub
Hub has been specifically configured to run on the following
2.1 PFS on pfs.demo001.env.raiden.network
2.2 Transport on transport.demo001.env.raiden.network
Node1 and Node2  select the
3.1 Transport as transport.demo001.env.raiden.network but
3.2 PFS they sometimes select
3.2 a pfs.demo001.env.raiden.network and this is time when the tranfer has correct route and the transfer goes through. At the time the nodes dont see the other PFSs and act as if  pfs.demo001.env.raiden.network is the only PFS available. Unfortunately i did not take a screenshot for this.
3.2 b Sometimes the nodes use all the other PFS's like pfs.transport0x.raiden.network (where x is a number) but do not see the pfs.demo001.env.raiden.network as if it never exists.

The next step they get No route between you and target

This causes one way transfers even though capacity exists either way.
Lots of users on gitter are facing the same issue and are utterly confused why they cannot make a simple transfer and why the hub is always offline or something which can happen when hub is on transport.transport0x.raiden.network and pfs.transport0x.raiden.network
Expected Result

Each time depending on the transport server that has been picked up the correct PFS should be picked up.

Actual Result

Has been described above

Observations using local LC nodes as opposed to the staging ones
using the staging environment file .env.staging for locally deployed nodes
yarn workspace raiden-dapp run serve --mode staging

the nodes pickup transport02 server for transport and query all the PFS's at the time of route selection.
The hub needs to be on the transport0x servers otherwise the again we would get No route between you and the target above.

Finally if we use a environment file for example like this
VUE_APP_PFS=https://pfs.transport02.raiden.network
VUE_APP_MATRIX_SERVER=https://transport.transport02.raiden.network
VUE_APP_HUB=hub.raiden.eth
VUE_APP_ALLOW_MAINNET=false
VUE_APP_IMPRINT=https://raiden.network/privacy.html

and start the servers
yarn workspace raiden-dapp run serve --mode testnet
in this way the PFS selection is forced in the dapp to use only that one PFS which we have specified in the environment file.

I reach the conclusion that till we have this disjoint transport servers with staging environment not explicitly specifying a PFS this confusion is there to remain
@talel

Observations using local LC nodes as opposed to the staging ones
using the staging environment file .env.staging for locally deployed nodes
yarn workspace raiden-dapp run serve --mode staging

the nodes pickup transport02 server for transport and query all the PFS's at the time of route selection.
The hub needs to be on the transport0x servers otherwise the again we would get No route between you and the target above.

Finally if we use a environment file for example like this
VUE_APP_PFS=https://pfs.transport02.raiden.network
VUE_APP_MATRIX_SERVER=https://transport.transport02.raiden.network
VUE_APP_HUB=hub.raiden.eth
VUE_APP_ALLOW_MAINNET=false
VUE_APP_IMPRINT=https://raiden.network/privacy.html

and start the servers
yarn workspace raiden-dapp run serve --mode testnet
in this way the PFS selection is forced in the dapp to use only that one PFS which we have specified in the environment file.

I reach the conclusion that till we have this disjoint transport servers with staging environment not explicitly specifying a PFS this confusion is there to remain
@talel

@weilbith Describe issue and our solution to the problem.

Alight, let's give this a try.
The root of all the described symptoms is that while the development and staging environment share the same contract deployment, their associated RSB deployments are different.  Thereby we get an awkward 50% connection of both environments.
In our discussions we pointed out two possible solutions. Either make both fully connected (100%) or completely separate them as two (0% connection). Merging both environments completely seems to be a bad idea as they have different purposes. The staging environment is meant to be used for test network demonstrations of the Raiden clients. As a environment for external developers to try the system and get familiar with the libraries to build their own products on top. Therefore it is meant to be stable and reliably working. Though it has not as strict reliability constraints as the mainnet.
The development environment is meant to be used for internal engineering. Basically the step after the end-to-end tests, like for the Scenario Player. An environment where the RSB is always on latest version. Where unstable/unreleased features of the services can be tested. Thereby it is less stable and reliable than the staging environment. But all eventual issues stay internal and only hinder our own daily development flow. Deployments can be way less formal and hacky if necessary.
Therefore it is the currently favored approach to separate both networks. As the stable version the staging environment should stay as is and the development environments pops out. This requires us to

make a new contract deployment on Goerli
the current active services for the development need to change their contract pointers and probably a fresh state
all client configurations related to the different environments need to adopted

The following steps on this topic are:

align on the decision and solution approach
complete the task list
decide if each client implementation needs its own development environment
create actual issues for the tasks in the list
assign issues and prioritize them in the imperative order

@palango @andrevmatos could you eventually provide some feedback, especially regarding the task list, as I'm not familiar with the Raiden service bundle.

Looks good to me, I think it's important to first align on the approach, we can work out the details afterwards.

I think that should be about it. Some observations:

I'd like the clients to continue using the same network, it makes it easier to cross-test.
at least on LC, the state key/db/name uses contains the TokenNetworkRegistry address, so a new deployment automatically generates a new state
Please, let's try to re-use as much contracts as possible; e.g. at least the tokens and service token contracts can be reused without issues, and save us calls to mint them again.

Maybe SecretRegistry is safe to be reused as well.

the clients (at least LC) picks automatically the goerli addresses from the JSON file from the raiden-contracts repo. I think the file there should remain pointing to the stable deployment, but then we need to ensure that the right contracts are used on development/staging servings of the LC and PC. The LC supports auto-detecting the addresses from a single entry-point contract (UDC address), we just need to expose this on dApp to pick from the env vars, and have them set in the development/staging .envs.

Looks good to me, I think it's important to first align on the approach, we can work out the details afterwards.

@palango who would you suggest to take into account. So we could just mention them here.

Please, let's try to re-use as much contracts as possible; e.g. at least the tokens and service token contracts can be reused without issues, and save us calls to mint them again.

Good idea. Should be safe to re-use the tokens from my perspective. In my opinion they are actually not part of the Raiden contracts themselves.

The LC supports auto-detecting the addresses from a single entry-point contract (UDC address), we just need to expose this on dApp to pick from the env vars, and have them set in the development/staging .envs.

Yes. I remember. We just have to do it. :grimacing:

@eorituz @ezdac @karlb @ulope could you have a look from here and provide some feedback? We could also schedule a meeting if the opinions diverge too much or there are many questions.

I'd like the both clients to use the same network, it makes it easier to cross-test.

I agree.

Maybe SecretRegistry is safe to be reused as well.

It is and there are plans to reuse it even on mainnet for a long time: https://github.com/raiden-network/raiden-contracts/issues/1182

e.g. at least the tokens and service token contracts can be reused without issues

Reusing the tokens is definitively a good idea and has been advocated multiple times already. It would cause less confusion and make the testnets more similar to the mainnet, since the mainnet also uses the same tokens on each deployment. The necessary changes to the deployment have just never been done.

Using different contract deployments will provide a nice clean split. Coordinating the contract changes across all the different repos could be error-prone, though. Does anyone have a clear view on how that would work in detail, yet?

@taleldayekh organise meeting about this.

Another approach would be to reject PFSs that are not operating in the same federation (we could add a federation id to the info endpoint if the existing info is not sufficient) and look for another PFS. That behavior is useful anyway and would avoid the need to add any new configuration. This would be less prone to strange errors due to misconfiguration.

I would suggest to move the demo environment to rinkeby.
Pros:

completely separate deployment
no extra code necessary
Cons:
don't know?

I just checked that the contract deployment on rinkeby is up to date. So we could start using rinkeby for the demo env right away.

Counter-argument from @eorituz:

Isn’t there another way than moving the demoenv to another network? This will kill all services, demos and applications running on demoenv
It would also require to redeploy tokens/set new tokens and funds nodes….

My suggestion would be to move the LC away from demoenv and use a newly deployed "testenv".
The demoenv would stay as it is and all demos keep on working. (The idea of the demoenv was to be as long living as possible and only update it if raiden has major updates/improvements)
Also, we could prevent this conflict of interest for future occurrences.

This is not about LC. The "stable" LC uses is expected to continue using the demoenv. The "unstable"/staging LC is expected to stay on the PC's testnet (transport0*). It's more about ensuring these two networks either can talk properly, or are fully disjoint (by e.g. moving the testnet to a new contracts deployment). The specific issue here should also happen on PC, if for any reason it tries to talk to hub.raiden.eth node or the maybe pick the demoenv's PFS. It only got detected first on the LC because we have specific environments using each of them, and also hardcode/defaults to suggesting the this HUB on our deployed instance.
I think, since the demoenv is currently being used outside BB, we should move the PC + LC testnet (transport0[1-5]) matrix & services to a new Goerli contracts deployment, leaving the current network only for demoenv.

I think, since the demoenv is currently being used outside BB, we should move the PC + LC testnet (transport0[1-5]) matrix & services to a new Goerli contracts deployment, leaving the current network only for demoenv.

Yes, here is my proposed course of action:

[ ] create a new goerli contract deployment with the codename unstable, that's to be used with transport[1-5], internal scenario player, PC & LC testing
[ ] Introduce a special case chain id, GOERLI-UNSTABLE, to the contract manager for selecting this deployment.
[ ] Add a configuration value for PC (LC, too?): --development-environment [demo (default) | unstable]. The default, demo, will point the client to the existing services contract using the known mechanism. The unstable setting will use the new contract deployment by means of using the special chain id from above.
[ ] Update CI infrastructure (i.e. scenario-player) to use the --development-environment unstable flag.
[ ] If there ever is an update to the "stable" demo docker container, that is build on more recent PC code, we must also update the demo deployment. In other words move to a demoenv002. This is due to the changes in the services communication model, switching to toDevice chatter to registered service addresses.

This should avoid any breakage of existing demos and prevent future spillover.

The new contracts are set up and used in the services-dev services and the services on transport05 as well as by the SP CI development.json environment.
Remaining TODOs:

[ ] Update services on transport01-04 to use these contracts
[ ] Allow LC to use these contracts
[ ] Configure LC to use these contracts when run in SP CI
[ ] Demo env and development_environment: unstable work. Service discovery does not work in demo env, but is also not used, usually. Decide if that is enough.
[ ] Update docs if neccessary

Can we close this ones our next branch has been merged to master? @taleldayekh

Closing, next is noe merged to master.


CompilerSelector: prefer the gcc verion offered by the gcc formula

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

When GCC is used (default for Linux), we should prefer the gcc offered
by the gcc formula. As such even if users install a gcc with higher
version from gcc@* formula, it will not be picked up to build other
formulae. This would also allow users to safely delete gcc@* formula.
Closes #5953.

Thanks for the PR @xu-cheng!

Thanks again @xu-cheng!


Add port ranges

Use the ability of ranges with iptables instead of creating multiple
rules for each port.
Signed-off-by: Brent Baude<EMAIL_ADDRESS>

@baude I think there is something up with the code. Cause the example you were trying with -p 8080-8082:80-82 works with main branch without this PR. So podman is for sure splitting port forward into seperate entries rather than using range field.
I wonder if we only need this PR for -p 8080-8082:80-82 then it works with firewall disabled from the current main without any addition.
For range part i think there is something up with the code cause tests looked fine to me.

@flouthoc You can run with --log-level trace, this will show you the exact config for netavark. I am pretty sure -p 8080-8082:80-82 creates a range, if not than this is a bug

@Luap99 I'll try that but could you also confirm if this works for you from main branch. run -it -p 8080:8082:80-82 quay.io/libpod/alpine_nginx and make sure you switch the backend to netavark.

I am on PTO. I have no access to my workstation so I cannot test netavark

@baude cargo fmt is needed.

/lgtm

Please restore the internal test and add the ip=dual case as noted in the review e ts


Restrict scanning for concrete types over specific packages

Class scanning is a great feature, but depending on the size of your project, it leads to some minor issues. For example, I'd like to use EasyRandom as part of the test harness for a project. The test harness has its own module as it gets included into different module. Scanning for types may end up finding different implementations of the interfaces depending on the module in which the test harness is pulled. I'm sure that's a nice use case for some, but it can also lead to some issues. For example, the test harness module already pulls in a dependency which has concrete implementations of some types. These are beans and can easily be generated by EasyRandom. However, maybe in another module, there are other implementations which run into limitations of EasyRandom, or which aren't strictly beans. In this case, it would be great if I could specify which implementations to use.
Secondly, scanning the whole class path can be prohibitively expensive. This isn't a big overhead when running a complete test suite, but when running single tests in your IDE having it add a few seconds for a test which takes 5 milliseconds is a bit tedious.
Now, neither are blockers, but restricting the scanning to specific packages seems like a pretty easy fix - this is already supported by ClassGraph, and it would fix both issues.
Let me know if I wasn't clear. If this is something you'd consider, I'm also happy opening the PR myself.

I would propose something slightly different, in the end. Introduce a new interface in the API:
/**
 * Interface describing the API to resolve concrete types for a given abstract type.
 *
 * For example, a resolver which resolves all {@link java.util.List} to {@link java.util.ArrayList},
 * and delegates other types to the default resolver:
 *
 * <pre>{@code
 * public class ListConcreteTypeResolver implements ConcreteTypeResolver {
 *   <T> List<Class<?>> getPublicConcreteSubTypesOf(final Class<T> type) {
 *     if (List.class.equals(type)) {
 *       return ArrayList.class;
 *     }
 *
 *     return ConcreteTypeResolver.defaultConcreteTypeResolver().getPublicConcreteSubTypesOf(type);
 *   }
 * }
 * }</pre>
 */
@FunctionalInterface
public interface ConcreteTypeResolver {

  /**
   * Returns a list of concrete types for the given {@code type}.
   *
   * @param type the abstract type to resolve
   * @param <T> the actual type to introspect
   * @return a list of all concrete subtypes to use
   */
  <T> List<Class<?>> getPublicConcreteSubTypesOf(final Class<T> type);

  /**
   * @return a default concrete type resolver which will scan the whole classpath for concrete types
   */
  static ConcreteTypeResolver defaultConcreteTypeResolver() {
    return ReflectionUtils::getPublicConcreteSubTypesOf;
  }
}

This interface's default implementation is then the current type scanning mechanism, i.e. the one which relies on ClassGraph. By having this simple interface, users can submit their own ways of scanning for concrete type, which could be reusing ClassGraph but with various filters. This avoids coupling easy-random to ClassGraph via its public API.
I'll open a PR, let me know what you think. I know technically this is a new feature, and I understand the project is in maintenance mode, but I hope it's small enough you might consider it :slightly_smiling_face:

For those wondering, the current workaround is to register a randomizer for every abstract type, mapping to a list of known concrete types. So you could reuse ClassGraph yourself, for example, if you had two types, com.acme.super.cool.package.MyAbstractType and its implementation, com.acme.super.cool.package.impl.MyConcreteType:
final CustomRandomizerRegistry randomizerRegistry = new CustomRandomizerRegistry();
// the .. at the end specifies to look at all sub-packages as well
final ScanResult result = new ClassGraph().acceptPackages("com.acme.super.cool.package..").scan();
result..getAllInterfaces().forEach(abstractInfo -> {
  abstractInfo.getClassesImplementing().filter(ClassInfo::isStandardClass).directOnly().forEach(concreteInfo -> {
    randomizerRegistry.registerRandomizer(abstractInfo.loadClass(), concreteInfo.loadClass(abstractInfo.loadClass()));
  });
});
final EasyRandom random = new EasyRandom(new EasyRandomParameters().randomizerRegistry(randomizerRegistry));

// this will create an instance of MyConcreteType
final MyAbstractType instance = random.nextObject(MyAbstractType.class);

Hope this helps anyone else!


More detailed error message when scanning qr code which is invalid for checkin

Avoid duplicates

[x] This enhancement request has not already been raised before
[x] Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
[x] If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation
In https://github.com/corona-warn-app/cwa-app-android/pull/2919 the error message became human friendly for issue #2909.
Suggested Enhancement
Explain that the qr code itself may be valid, but not for check in.
When I scan a valid qr code as a test-qr-code, there is a very detailed message, what can be wrong with the qr code.
Expected Benefits
The user may have a valid qr code for a test (or something else) and will get an explanation what might be wrong with this qr code. He won't become confused.

Internal Tracking-ID: EXPOSUREAPP-6761

The user may have a valid qr code for a test [...]

This has also been mentioned in https://github.com/corona-warn-app/cwa-app-android/issues/2909#issuecomment-824789923.
The same issue applies to iOS, so I'd suggest to move it to either the wishlist or the documentation repository, depending on wether this is seen as a bug or as an enhancement request.

In https://github.com/corona-warn-app/cwa-app-android/issues/2909#issuecomment-825035414 you can see, that iOS users get a message, which says that the qr code cannot be used for check in (but might be valid itself).

@DerVogel2020
Could you share a screenshot of the error message under Android?

@DerVogel2020
Could you share a screenshot of the error message under Android?

No, not now. Linked to the strings.xml of the commit.

@DerVogel2020
I agree that iOS is better than Android in this case.
Let's keep this issue here and we can open a new one in the wishlist reg. the scanning of a test QR-Code with the event-registration scanner.

Here is now a screenshot of CWA 2.0.4

@DerVogel2020
Thanks for the report. We have brought this to the attention of the development team.

Corona-Warn-App Open Source Team

Hey everyone,
We cannot do much about this unfortunately. There are many combinations of QR-code details which are not valid, but it's not really possible for CWA to give more reasonable info. Not within realistic effort at least.
Therefore, we will close this issue.

Corona-Warn-App Open Source Team

but it's not really possible for CWA to give more reasonable info

OK. But what about the message from the iOS repo? Just created #3046.

@DerVogel2020 Ah if it's about aligning the iOS and Android messages then it's probably fine. Sorry for the misunderstanding.
I will clear up the misunderstanding internally. Looks like your PR will be approved. Thanks again for contributing :)

Corona-Warn-App Open Source Team

@harambasicluka you may add the Fix2.2-tag.

Fixed in 2.2.1.


Default route for '/' not in web middleware group after make:auth.

After firing php artisan make:auth to scaffold a basic authentication system, the route '/' which renders the welcome view, is not placed inside the web middleware group.
This is a problem since without the web middleware group, the sessions aren't started and thus the welcome view can't check if a user is logged in or not, so it will always display the login and registration links, even if the user is logged in!
This can be easily reproduced by installing a new Laravel installation, and then running php artisan make:auth & php artisan migrate.
Then you register and login with a new account, and then you are logged in at the '/home' page, but not at the '/' page.

This is intended.


How to make the table row multiple lines instead of horizenal scroll

If the row is too long. The scroll comes out. It is not what I want. How to make it multiple lines.

ß
Sent from Mobile2ãez
On Jul 22, 2016 2:52 PM, "707"<EMAIL_ADDRESS>wrote:

If the row is too long. The scroll comes out. It is not what I want. How
to make it multiple lines.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/connors/photon/issues/115, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKqBt7vi3cjJLtXKYSpF-niy3ATkjKE-ks5qYLzygaJpZM4JSutV
.


Android Crosswalk and Target API

Great work on unifying this plugin and adding Android support!
What is the current status of this plugin with crosswalk? I'm happy to test support if you haven't already.
I notice you @TargetApi level 21, is that the plugin's minimum support?

Hi, this plugin has not been tested with crosswalk. TargetApi level can be lower than 21, but I haven't tested them.
Regards,Zibin
  From: Lee Crossley<EMAIL_ADDRESS>
To: zxyang/cordova-plugin-clientcertificate<EMAIL_ADDRESS>Sent: Tuesday, May 3, 2016 11:19 AM
Subject: [zxyang/cordova-plugin-clientcertificate] Android Crosswalk and Target API (#1)
Great work on unifying this plugin and adding Android support!What is the current status of this plugin with crosswalk? I'm happy to test support if you haven't already.I notice you @TargetApi level 21, is that the plugin's minimum support?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub