dataset-CL reconciliation via the ontology ui

We should create a graph linking nodes in the cell ontology to labels in a particular dataset. The edge thickness should be proportional to the number of cells overlapping the linked labels.
Users can then investigate this graph to see which labels are mapped to which nodes in CL - do these links make sense? For example, if a cell type is mapped to a node in CL that is too coarse whereas a more accurate & fine-grained CL term exists, then these cells should be relabeled to the proper CL term in the dataset.
Example to demo on:

Dataset: https://cellxgene.cziscience.com/e/066943a2-fdac-4b29-b348-40cede398e4e.cxg/

Label: original_ann_nonharmonized

Example scenario indicating success:

User views map of CL labels linked to fine-grained manual annotations
User finds one CL term linked to 8 different manual labels
These labels can intuitively group into 2 subgroups
Curators add two new CL term children to capture this specificity

basal resting diffexp


Add date and time on various order details

Date and time are not detailed on those elements:

Shipping (it would be nice to see when we confirmed shipping)
Funds: we need to open the block explorer to get transaction broadcast times
Discussion: messages are not timestampped

Is it possible to add these details?

The API returns messages with timestamps so this is easy to add.
However I don't see the API returning the time of shipping confirmation or funds being broadcasted on the network (I don't think this is necessary to duplicate in OB).
If this is added on the server side I can add it to the client @cpacia


⚠ GazelleGames has degraded performance

In 840f36d, GazelleGames ($GGN) experienced degraded performance:

HTTP code: 200
Response time: 2869 ms

Resolved: GazelleGames performance has improved in 7bf8c87.


feat(int-pymongo): generate traces for beanie

Codecov Report

Merging #100 (0410d4e) into main (28bf7ef) will increase coverage by 0.40%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #100      +/-   ##
==========================================
+ Coverage   87.77%   88.17%   +0.40%
==========================================
  Files          13       13
  Lines         499      499
==========================================
+ Hits          438      440       +2
+ Misses         61       59       -2

Impacted Files
Coverage Δ

cisco_telescope/tracing.py
93.87% <0.00%> (+4.08%)
:arrow_up:

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 28bf7ef...0410d4e. Read the comment docs.


Support for a mask during autoregressive generation with Key-Value Caching

Why isn't a mask supported when key-value caching is enabled here?

@Oufattole in what scenario would you need masking when doing autoregressive decoding?

I'm trying to do sliding window inference, but the lengths of the initial prompts are different in my transformer, so I think I should mask out the padding as that's what we do during autoregressive pretraining.

@Oufattole yes I see, so you are off the beaten path
sliding windows transformers isn't supported here yet

Ahhh I see thank you, I'll try that! With medical data, unlike in NLP and CV, many patient trajectories are very small and you don't need a long sequence length at all. For example, with my dataset 80% of patients are below the 512 max sequence length, but a small subset of patients are punching over 30k (this is after extreme reductions in the vocabulary -- i.e. which time-series variables we model, prior to which some of these patients hit over 300k).
I naively am trying to use sliding windows, but if there is a better approach you recommend for handling such extreme sequence length variations, I would be happy to try it.

Wait, actually, I think you do support masking the left padded tokens with the seq_start_pos arg here @lucidrains .

@Oufattole so that hyperparameter was actually built for variable prompt lengths iirc
during sliding window, you'll have to slice the cached key values as you decode out of the window length

@Oufattole what specialty is this and what exactly are you trending in the EMR that hits 300k in length?

Yes, I think you already do slice this kv-cache slicing during generation here when restricting to the max_seq_length (i.e. in the sliding window setting). Am I correct about this?
I'll send you an email in regard to the broader EHR modeling question, which I realize may be out of scope for this github issue.


”Hamcearca”, ”Balabancea”, ”Căprioara”, ”Nifon” are listed in the drop-down menu

Description:
When user writes ”Hamcearca”, ”Balabancea”, ”Căprioara”, ”Nifon” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Hamcearca"

Expected results
The location appears in the drop-down menu as "Sat Hamcearca, TULCEA (Hamcearca)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Balabancea"

Expected results
The location appears in the drop-down menu as "Sat Balabancea, TULCEA (Hamcearca)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Căprioara"

Expected results
The location appears in the drop-down menu as "Sat Căprioara, TULCEA (Hamcearca)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.


Locality not populated

Hi, I've noticed that most of the addresses within my own locality do not have the locality populated.  Is there a mechanism by which we can update these and resubmit in bulk?
Many thanks
Andy

Hi Andy,
For the time being our parser is dropping the locality names where the address is unambiguous even without using it, typically when a postcode is specified. Other users like you have challenged this choice, too. What do you reckon?

Gianfranco,
I see it as being an issue for small businesses and business where different people are doing order entry and service delivery.  If I look at ‘CHURCH STREET’ in ‘DONCASTER’  I have postcodes in DN3, DN5, DN9, DN10 and DN12.  For the smaller business, especially mobile who needs to find their destination e.g. plumbers, dog groomers, cleaners, carers etc., with the LOCALITY known they can start to head towards a destination, without it they will need to look it up or have satnav.
Hope this helps.
Many thanks
Andy

I agree too that in later releases localities should be preserved, and not only! With @murraydata for example we talked often about the importance of 'vernacular' localities: localities that you won't even find in our "reference tables" but that are very meaningful to the people there.
@peterkwells you don't need a new entry in the roadmap: this is part of the work we need to do on revising the address model https://github.com/OpenAddressesUK/roadmap/issues/66 . Just add it there as one of the requirements to address.


Improve communication with driver

The suggestion is to improve communication with driver.
The concept of 'driver' suits most simple cases, but the interaction with driver is allowed at configuration time. The template for X-ray driver is
function driverFactory(opts) {
  var agent = superagent.agent(opts || {})

  return function driver(ctx, callback) { ... }
}

There's may be no driver factory function at all or it can be a class, the result is the same - a driver (driver function) can get configuration-time data from parent scope or some context (if supplied to X-ray as driver.bind(context)).
It appears that run-time data is supplied to driver as ctx with no possible extra arguments, and ctx.url is the only thing that driver shares with outer world on run-time and the only thing that can be affected by X-ray API.

To my knowledge, the only type of hooks that can be used to intercept and transform data are filters. Let's suggest that we need to pass some of the data from current field to following request. Data is some run time stuff - session ID or any value that should be taken into account by the driver on next request.
This works as long as data is supposed to be passed in URI via GET:
const x = Xray({ filters: { tokenInterceptor } }).driver(driver);

const tokenInterceptor = (token)`${URL}?token=${token}`;

x('...', [{
  nested: x('[data-token]@data-token | tokenInterceptor', .nested');
  ...
}])

It may even for complex scenarios where several fields are supposed to be used together, because filter function has got this.$, which may be used to make custom selections.
The limitations appear when passed data is supposed to be used by the driver as anything but URL. A cookie, a header or POST data - name it all. Current design makes not just complicated but impossible. The only way is to break a chain, iterate through results and attenuate the driver to use relevant cookie/header/whatever... looks like we've just efficiently defied the purpose of crawler and returned to low-level request+cheerio tandem.
ctx context is formed by x-ray-crawler, the only thing that it accepts from the outside (namely, filter function) is URL. It is not possible to just pass an object instead of url, because it is validated before following request. To be passed to driver, data should be serialized and appended to URL, then driver may split data from URL and unserialize it!
I see no way to overcome design flaws by other means than serialization hack. How can the situation be improved?


OPENJPA-2730 Update to ASM 6

LGTM: @rmannibucau or @struberg do you see any issue for ASM upgrade?

yes, the ASM constant was not updated (see https://github.com/jgallimore/openjpa/blob/211cea18b34afe66a8c4d91d03db48a44d0be1d3/openjpa-kernel/src/main/java/org/apache/openjpa/enhance/AsmAdaptor.java#L119 for instance). Once done you can merge @ilgrosso

thanks @rmannibucau / please @jgallimore make the changes request
Does it make sense to merge this PR to 2.4.x as well? For instance, is ASM 6 compatible with Java 7?

Think so yes

Thanks, I'll update that. I have the change for 2.4.x too.

I have the change for 2.4.x too

Cool :-)

Updated, and also submitted https://github.com/apache/openjpa/pull/12 for 2.4.x.


WIP: Non-blocking filtering

This PR moves the fuzzy matching off the main thread for much improved responsiveness. It also only executes the fuzzy matching after 50ms of no typing activity to decrease the number of searches significantly which should save battery life.
I haven't used it enough to make sure it's stable, would like to have people help me test this particular branch.

[ ] Add ability to configure delay

Whoops, found a critical crash. Don't use yet

Fixed

Cool! Did you try to measure somehow the increase in responsiveness to see what helps? Does moving into background queue actually help? Or is it solely the effect of adding the delay? I am worried that not everything we are using is safe to use from another thread than one calling setFilteringPrefix:...
Since it is a sensible thing to do, it might be the case that Xcode already calls setFilteringPrefix: with some sort of delay mechanism to prevent multiple calls when typing fast. Maybe it simply is shorter and we can override delay there and make it configurable?
Why store _fa_forceFilter instead of passing it as an argument to _fa_kickFilterTimer and then to _fa_performFuzzyFiltering? Not that we actually use it, but seems more error prone to store it.
Why NSOperationQueue over GCD? I don't see much cancellation logic within the methods (besides the check just before setting the results). Maybe simply using a serial gcd queue would be good enough?
I think the suspicious nil you were seeing would be the case in which DVTTextCompletionSession was finished and was retained only by the async block. We might try to detect this case somehow and break earlier.

Hey guys! I've been using this branch all morning and seems to run pretty well.
Although I just noticed this, if I type each letter of something that pops up in the autocompletion this happens:

So, say I want to type all the characters in NSString
type: N screen: N
type: S screen: NS
type: S screen: NSS
type: t screen: NSSt
type: r screen: NSStr
type: i screen: NSStri
type: n screen: NSStrin
type: g screen: NSStrin      nothing happens
type: 1 screen: NSString    the previous character appears and the autocompletion box closes
type: 2 screen: NSString1
type: 3 screen: NSString21
...

@slazyk:
No hard measuring, purely subjective, but given that filtering takes 100-200ms for me, having it no longer block the main thread makes it significantly more usable. From what I can see, Xcode doesn't call it with a delay because prefix-only matching is fast enough to not warrant the extra complexity.
Good point on storing forceFilter, I'll change it. Wanted to make sure there was no major stability issues first before focusing on cleanup.
I picked NSOperationQueue to make it easy to purge all existing operations when queuing another one. I'd have to add more stuff to do that with pure GCD.

@mokagio that's crazy! I can't seem to reproduce that locally at this stage though. Does it happen 100% of the time for you?

@chendo yes, 100% of the times I type all the characters. There's more, this is what happens when typing NSDecimalNumber

I built the project from 21b879a, and I'm using Xcode 6.1.1 (6A2008a)

Regarding the speed, it feels smother to me too :smiley: But would be interesting to see how much it actually is.

@mokagio what settings are you using? I'm on the same build of Xcode and tried changing a few settings but still can't seem to reproduce

@chendo I'm using the defaults settings. What other information can I give you?
Before building the feature branch I removed the plug-in via Alcatraz, restarted Xcode, then built the project.

@mokagio if you could screenshot me each settings page that'll be tops. Also can you confirm it's that branch by going back to the alcatraz package?

Yep it seems to be the branch. I just reverted back to the Alcatraz version (2.1.0), and it behaves as usual.

Copied settings exactly and now I can reproduce

You can avoid the problem by disabling inline preview for the time being. Personally, I prefer it have it turned off to easier see what I'm typing

Ok, glad that you can reproduce, first step to fix it :+1: :smiley:

Hard to reproduce because who actually types ALL the characters? :laughing:

@iosengineer lol that's true, it's the whole point of the plugin right? 😛
I found it out when writing a variable named description that clashed with a snippet I have that's triggered by desc.

@chendo merrrgggeee thissssssss

I haven't been able to revisit this recently but the plugin hasn't crashed for me in the last couple of weeks.
@slazyk good point regarding the forceFilter variable, I'll remove it when I have the time. Any other issues?

I haven't tested much, but was able to reproduce what @mokagio reported, and also remember seeing wrong results in some cases, let me investigate a little.
BTW I should have some spare time soon, I can try finishing this up if you don't have the time.

Personally, I think showing inline preview makes correcting a typo harder so I have it off, which is why I didn't notice while developing. Are there stats on how many people have the option turned on?
Cool, that's fine by me.

Any updates about non-blocking filtering?

Superseded by #102


Choose Columns view is not DPI aware

Describe the bug
The choose columns view is not DPI aware.
To Reproduce

Connect to windows via RDP, from linux I use this: xfreerdp /gdi:hw /rfx /rfx-mode:video /scale:180 /scale-desktop:200
Start Process Hacker
Right click on the columns -> Choose columns...

Expected behavior
The choose columns view to be DPI aware.
Screenshots

Desktop (please complete the following information):

OS: Windows
Version 10

Additional context
I am connected via RDP to a VM, and set the DPI settings there. Maybe this causes the issue?

I am connected via RDP to a VM, and set the DPI settings there. Maybe this causes the issue?

The item height wasn't scaled when DPI was >= 150%... I've fixed the issue in the latest nighty build. You can trigger the update by using the Help > Check for updates menu.
Thanks for reporting it 🍺

I am connected via RDP to a VM, and set the DPI settings there. Maybe this causes the issue?

The item height wasn't scaled when DPI was >= 150%... I've fixed the issue in the latest nighty build. You can trigger the update by using the Help > Check for updates menu.
Thanks for reporting it 🍺


WIP - first pass at a CodeQL config for Java

What and why?
Spike: Investigate Github Action CodeQL
How to test?

TBD

Trello

https://trello.com/c/oGMjzmgB

We'll enable via the UI but this is great


IID Optimizer writes zero byte patched DLL on exception

If the optimizer throws an exception, it corrupts the patched DLL, writing zero bytes.  Workaround is to disable optimization via CsWinRTIIDOptimizerOptOut.
Build log excerpt from a recent WinUI build follows:
2021-08-04T22:12:11.9946856Z CsWinRTInvokeGuidPatcher:
2021-08-04T22:12:11.9947992Z   "C:\a\1\s\packages\microsoft.windows.cswinrt\1.3.3\build\tools\IIDOptimizer\IIDOptimizer.exe" @"C:\a\1\s\BuildOutput\obj\x86chk\controls\test\MUXControlsTestApp\TAEF.Desktop\MUXControlsTestApp.TAEF.Desktop\net5.0-windows10.0.18362.0\win10-x86\IIDOptimizer\cswinrt_iidoptimizer.rsp"
2021-08-04T22:12:11.9958642Z   "C:\a\1\s\packages\microsoft.windows.cswinrt\1.3.3\build\tools\IIDOptimizer\IIDOptimizer.exe" @"C:\a\1\s\BuildOutput\obj\x86chk\controls\test\MUXControlsTestApp\TAEF.Desktop\MUXControlsTestApp.TAEF.Desktop\net5.0-windows10.0.18362.0\win10-x86\IIDOptimizer\cswinrt_iidoptimizer.rsp"
2021-08-04T22:12:12.8969155Z   Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
2021-08-04T22:12:12.8970165Z    ---> Mono.Cecil.ResolutionException: Failed to resolve Microsoft.UI.Xaml.Controls.ScrollingInteractionState
2021-08-04T22:12:12.8970875Z      at Mono.Cecil.Mixin.CheckedResolve(TypeReference self)
2021-08-04T22:12:12.8971497Z      at Mono.Cecil.MetadataBuilder.GetConstantType(TypeReference constant_type, Object constant)
2021-08-04T22:12:12.8972168Z      at Mono.Cecil.MetadataBuilder.AddConstant(IConstantProvider owner, TypeReference type)
2021-08-04T22:12:12.8972865Z      at Mono.Cecil.MetadataBuilder.AddField(FieldDefinition field)
2021-08-04T22:12:12.8973443Z      at Mono.Cecil.MetadataBuilder.AddFields(TypeDefinition type)
…
2021-08-04T22:12:12.9241771Z CsWinRTReplaceForPatchedRuntime:
2021-08-04T22:12:12.9243130Z   Copying file from "C:\a\1\s\BuildOutput\obj\x86chk\controls\test\MUXControlsTestApp\TAEF.Desktop\MUXControlsTestApp.TAEF.Desktop\net5.0-windows10.0.18362.0\win10-x86\IIDOptimizer\MUXControlsTestApp.TAEF.Desktop.dll" to "C:\a\1\s\BuildOutput\obj\x86chk\controls\test\MUXControlsTestApp\TAEF.Desktop\MUXControlsTestApp.TAEF.Desktop\net5.0-windows10.0.18362.0\win10-x86\MUXControlsTestApp.TAEF.Desktop.dll".

Looks like the command-line-api wrapper we use is not passing the optimizer's exit code along when the program terminates


WRN-6758: Cross-Platform Enact Android - RangePicker: +/= do not show on number vkb

Checklist

[X] I have read and understand the contribution guide
[ ] A CHANGELOG entry is included
[ ] At least one test case is included for this feature or bug fix
[X] Documentation was added or is not needed
[ ] This is an API breaking change

Issue Resolved / Feature Added
On VKB, +/= are missing.
This problem only appears on Samsung devices because they use their own numeric keyboard. We can't solve it from the
knobs because we need to modify the storybook's code. I checked and the problem was reproduced on our Input component so I resolved it there.
Resolution
Added a check to the input and in case the device is a Samsung one changes the input type=number, so it opens a different type of VKB(added a new prop called inputMode so we have '-' at least).
Before

After

Additional Considerations
Links
WRN-6758
Comments

Thanks for the analysis and PR but,
Let's not merge this. This issue is not due to our component and also this issue can be found on other Android phones. I would not feel to add these workarounds for the knob.


Google social auth

I am trying to implement the social auth using google as provider. I created a google app , added my credentials on the admin social app  and  followed the same steps mentionned on the documentation (Facebook example). But I didn't understand how can I  get acces token to test the Api ?

if I understand your question correctly, you want an access token for testing. You can get it at https://developers.google.com/oauthplayground

if I understand your question correctly, you want an access token for testing. You can get it at https://developers.google.com/oauthplayground

@PascalOtto  Absolutely , this is what I am looking for.
Many thanks

@PascalOtto  Absolutely , this is what I am looking for.
Many thanks


invalid durations are always valid

Describe the bug
Create a clearly wrong duration, always results in valid
To Reproduce
const dur = moment.duration(1,"something, anything!");
console.log(dur.isValid());

Expected behavior
Should print false

See https://github.com/moment/moment/issues/1805
This behavior will  probably not change in the future.


Low level command for deploying built resources

As far as I know, there is currently no way to only use the "deployment" part of helm, and completely skipping the "building resources" part. So if I build my kubernetes resources for example with cdk8s and I then want to deploy them using helm, I would have to create a "Chart.yaml" file and write the resources in a file in a "templates" directory. Only then, I could use helm install or helm upgrade. And even then, helm would still treat my resources as templates and look for placeholders inside them, which doesn't really make any sense.
It would of course be possible to directly apply the resources via kubectl apply -f, but then I would miss out on features like pruning old resources, deployment success checking or rollbacks. So using helm with built resources would still make a lot of sense.
So it would be cool to have some kind of low-level command to do just the deployment part of helm. I haven't looked into the source code, but building the resources and deploying them probably already is properly separated and I can imagine that it wouldn't even be that much work to implement this.
What do you think?

I think this would require a helm improvement proposal (hip). See https://github.com/helm/community/blob/main/hips/hip-0001.md

It turned out that it is already somewhat possible to just pass the finished kubernetes resources to helm and have it deploy them.
It's more of a workaround, though:
In the templates directory, you'll just need one single file containing the following:
// templates/resources.yaml
{{- range $resource := .Values.resources -}}
---
{{- $resource | toJson }}
{{ end }}

And then, if you have your resources as JSON, for example like this:
// resources.json
{
  "resources":[
    {
      "apiVersion": "apps/v1",
      "kind": "Deployment"
      /* ... */
    },
    {
      "apiVersion": "networking.k8s.io/v1",
      "kind": "Ingress",
       /* ... */
    }
  ]
}

They can be applied like this:
helm upgrade --install -f - --namespace my-namespace --create-namespace my-app ./ < resources.json
But normally, you probably wouldn't pipe static JSON resources to helm, but JSON generated by another tool.
I still think that it would be cool if helm supported that use case, but I don't have the time to create an HIP and therefore will close this.


[Refactor] Breadcrumbs Component

File Name
components/breadcrumbs
Reason for Refactoring the Code
It seems we're using different components or icons for breadcrumb navigation. Also, the component name and path should be fixed. It should be breadcrumbs instead of breadcrumps.

Checklist

[X] I have checked the existing issues.
[X] I have read the Contributing Guidelines.
[X] The changes don't break the code and don't introduce new functionality.
[ ] I am willing to work on this issue (optional).

Hey, Please assign this to me

@sarava338
I have assigned you the issue. Please proceed with it, and don't hesitate to tag us if you require any assistance.

I want to contribute in this project, free to assign some work to me.

I want to contribute in this project, free to assign some work to me.

This issue is already assigned to Saravanan.
So, you would have to look for new issues.
You can join the discord server of LinksHub and I will let you know whenever we have open issues to work on.


[KFNBC] Provide suitable error message for with inability of NB server to start

The system must provide suitable error messages related to the inability to start NB server sessions and enable the user to recover and try again immediately
Mockup for this issue can be found here:
https://marvelapp.com/prototype/28dc5af6/screen/78116147

[ ] Add UI to display the error to the user.
[ ] Add UI backend code to get the status and the error.
[ ] Integrate with KFNB controller.

Thought this was something else, apologizes for back and forth on the kind haha...

Should be covered by #351


"Top private" domain shouldn't be used for lnurls

When confirming payments and withdraws in lnurl, phoenix shows top private domain instead of a full domain name validated by a TLS certificate.
I can imagine an example where it's more beautiful and convenient than a full name, but such beauty has no place in payment handling and validation. For a random LN project with a domain outside public domain list, you have no idea who controls subdomains and whether they're semantically the same with respect to payment. There's a vast spectrum between "anyone can register" and "top domain owner controls all the content", and in no way it can be solved by any predefined lists in software.
My own service, https://lnurl-pay.me, has recently started using subdomains to support lightning address for fiat payments (like sending to<PHONE_NUMBER>111111@uacard.lnurl-pay.me). Even as I control everything there, I want the subdomain to be visible, and it would be much more important if some payout rails are outsourced to my partners (which may happen).
If there are any doubts concerning this, consider discussing the issue with lnurl-rfc contributors in https://t.me/lnurl.
Notice also that lnurl-pay rfc requires the host to be the same for the first and the second stage.  I was unable to find this check in phoenix lnurl-pay handling code, so I have no idea if it exists and whether it compares full hostnames, or just "top private domains". Consider ensuring that it is present and compares full hostnames.

Sorry, I was wrong about second-stage lnurlpay domain required to be the same asnthe first-stage one.
Somehow this restriction ended up in two popular lnurl implementations (lntxbot and BLW/SBW) without ever being in the spec.
Today, as many new services started to provide lightning address (basically non-bech32-encoded lnurlpay with user@domain syntax), some of them violate this extra-spec requirement (and some went even further by expecting a wallet to follow htrp redirect). Following the discussion in t.me/lnurl, I see that http redirects are out, but there's some disagreement about mismatching domains. Either the spec will be amended or lntxbot/blw/sbw will back off.
Perhaps to be on the safe side, it's better for phoenix to accept mismatching domains, at least until this restriction is in the spec.
If you decide to do it, please don't revert to showing "top private" domain — this part of my report was correct and important enough.

Perhaps to be on the safe side, it's better for phoenix to accept mismatching domains, at least until this restriction is in the spec.

Sounds good, thanks for the follow up.


Option to make selection fill the entire line on line breaks

In Emacs, when selecting across multiple lines, the selection expands to the fill the entire line on each line break (shown below).
Selecting text in a single line

Selecting text across line breaks

Selecting multiple lines

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


[da-vinci] Use interpolation for logging in da-vinci-client

This rb contains the logging clean-ups for the da-vinci-client module.
How was this PR tested?

Internal tests passed (green).
Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to explain your proposed changes and call out the behavior change.

Adam, thanks for the review. Proceed to check in.


Contact form addition to portfolio Website

The following features has been updated on the portfolio mobile website

Added a contact form section for users to send in their requests.
The contact form has been integrated with formspree to enable it store information.
The submit button in the contact form section now has a hover effect

Button Feature such as hover, enabled and disabled button have been added to the buttons


How to trigger a function in Child's window from Parent's window

Is it possible to access a global function defined in the child's window from the parent's window object? Does xcomponent or postRobot have this feature built in?
The use case is, when a user clicks a button in the parent component, I want the child component to respond to the click.
Thanks!

Hi @hafizio,
The best way to do this at the moment would be to define a function prop, and pass it down:
MyComponent.render({

    passMethod: function(method) {
        // now I have access to `method` from the child window
    }

}, '#container');

Then call it from the child:
window.xprops.passMethod(function() {
    // the parent will be able to call this function
});

Does that work for your use-case?

Thanks @bluepnume we'll try the solution and keep you updated. Thanks!

@bluepnume how do I execute the function callback passed into the passMethod? Because in the parent window, I can only access parent's props and not the passMethod. In the props object in the parent, it only contains the spec for the component and not the function itself.

@hafizio Not sure I follow. You should be able to just call the function:
MyComponent.render({

    passMethod: function(method) {
        method();
    }

}, '#container');

The way this works is:

You render MyComponent and pass down your passMethod method.
The child window calls passMethod, and passes a method up to the parent
passMethod is called on the parent window, and now has access to the method that is passed

Does that make sense?

@bluepnume Thanks for the reply. I tried the exact approach previously, but it doesn't work due to some some cache issues that we have. After disabling the cache, I bind the method to the parent's window object and it works perfectly.
Thanks a lot for you time!


Revert "Disable Android performance tests"

With https://github.com/gradle/gradle-private/issues/4085 resolved, it's time to add Android Studio performance test back.

@bot-gradle merge

The merge queue build has started. Click here to see all failures if any.


Make sure artifacts cannot be overwritten on download page

The s3-plugin that handles uploading our release artifacts will overwrite, with no way currently of preventing this on the server or client. This has resulted in 2.12.0 artifacts being regenerated from the same tag by the nightly job, and due to varying timestamps, they have different content and thus shas.
We should make sure this doesn't happen by construction. For now, I've added a note to the release checklist (and, of course, disabled the release job).
Multiple implementation strategies:

s3-upload to a staging area and promote them manually
or implement overwrite protection in the s3-plugin

In addition when we make a release we should publicly state their checksums.

that's https://github.com/scala/scala-lang/issues/463

Here are the sha256 sums for 2.12.0:
4fe80b742f31c5ec8141b04fe03acde6f8885777927943cde2f9be9fe6dab3b1  scala-2.12.0.deb
ccf0b764b912b382a2398c9583777b47163d27fd0ae3a88e59fc3b92ad1023ac  scala-2.12.0.msi
e9697e5bf14194d563ada4ac0df104fe8c155677969d98824d886bf54a702d20  scala-2.12.0.rpm
42be98ff9754518fd5c9a942c94ffba2464667a5e95ed4917e4e95565c96bdfe  scala-2.12.0.tgz
e6e6dadfb2c08a7da0e6095c0236a10969e057465bc283a1987a4a142ebabb42  scala-2.12.0.zip
41fb1eed6ffc68e4946f56af16e8270e0f722be7d88a64bc19fa1f861f13a0b7  scala-docs-2.12.0.tgz
4cb52f403339f961025de266adfaf75b5d4c15133bf0241f1e8ac058a6afc4c5  scala-docs-2.12.0.txz
01d90b2d7aad6c32a03552e34074710de3facebe0b1fa88f0b4eda31f04d04eb  scala-docs-2.12.0.zip

This script should be updated: https://github.com/scala/scala-dist/blob/2.12.x/scripts/jobs/release/website/archives

use https to download from downloads.lightbend.com
calculate sha256 sums and include in upload to epfl (chara)

the don't-overwrite part of this is probably still relevant, but the consensus on https://github.com/scala/scala-lang/issues/463 was to do gnupg signing instead of publishing checksums; that's now https://github.com/scala/scala-dist/issues/188

releases are now published from Travis-CI not Jenkins


 Due to some allegations u (the original developer) decided to make the code open source.

bro spent his time programming like 10k lines of code for a discord selfbot 💀

It was paid, now open source

balls

balls

fr

:skull:

💀

LOL


WIP: fix: pure web renderer

变动类型

[x] 日常 bug 修复

需求背景和解决方案
changelog
fix pure web renderer

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


NSDate compare in Swift 2.0

Hi , previously I'm compare date in swift 1.2 like the code below and it works fine :
let deleteArray = dataContext.articles.filter { $0.storeDate < dateToCompare}.toArray()
but after I update to 4.0.1beta to test with swift 2.0 it always shows me errors like :
Binary operator '<' cannot be applied to operands of type 'Attribute' and 'NSDate'
Any idea how to slove the problem ? thanks.

Hello. The storeDate managed object field is optional? Or dateToCompare variable?

I think both of them were not , if I try to casting storeDate (which type is Attribute) to NSDate like $0.storeDate as! NSDate ,it says it'll always failed. For dateToCompare I've also tried to unwrap it like dateToCompare!  but nothing works,that's all I know ,could these help? Thanks.

Can you put this somewhere in your existing code and see if the code compile?
extension NSDate: Comparable {
}

Sorry for the late reply Vmartinelli  ,looks like after I put the code into my file the errors has gone.Thanks for the help : )

You're welcome. :)


FOV Config - 1.19.2

Can you add a config option to toggle off the FOV change from being on paths?
This makes it less intense to the player when using paths

Great Idea!  I'll look into how to do this.
It will probably be a FOV reduction from 0% to 100% with a default of 50% reduction.


refactor: ship latest API stabilizations

Breaking changes

useScopedStyles() -> useStylesScoped()
useWatch$((track) => {}) -> useWatch$(({track}) => {})
useClientEffect$((track) => {}) -> useClientEffect$(({track}) => {})
useServerMount$(): Resource<> -> useServerMount$(): void
useMount$(): Resource<> -> useMount$(): void

Thanks Manu!
One issue that I forgot to mention yesterday - what's the difference between useWatch and useClientEffect ?
I'm guessing useCLientEffect$ is running only on the client... but why should we use useWatch then?

useWatch runs before the render, and can run in both places server and client. In the client it never runs eagerly.
We might need more docs about this

Thanks!
If that's the case, I think it might be less confusing to call it something similar to useClientEffect - like... useEffect ... or to change useClientEffect to useClientWatch to match them
Does it make sense?

This API has went through a lot of renamed in fact;
useWatchEffect,
useEffect, and finally useClientEffect.
We want to tag as client or server APIs that only run on those platforms, for now only useClientEffect and useServerMount.
useEffect would conflict with useEffect semantics in React, and that was also a reason to avoid that name.

Also, watch and effect has different semantics:

effect: after render
watch: on data change before render (giving a better time for updating data before render)


Adding me (chuemb) to the set of developers to get upload access for …

…absint-a3 plugin

Description
Link: https://github.com/jenkinsci/absint-a3-plugin
Please add myself (GitHub ID "chuemb") to the uploader group for the absint-a3-plugin

Submitter checklist for adding or changing permissions

Always

[x] Add link to plugin/component Git repository in description above

we need one of the existing maintainers to approve
Also if you want to be listed as one of the developers (who can release), we need you to login to jira and artifactory

Hey @chuemb,
to process this request, please

create an account on http://accounts.jenkins.io/
log in to Jira with the account created on accounts.jenkins.io: https://issues.jenkins.io/
log in to artifactory with the account created on accounts.jenkins.io: https://repo.jenkins-ci.org/
resolve the merge conflict

we need one of the existing maintainers to approve

It appears, the LDAP name is not an individual user but a GH org. Possibly @bschommer could approve this PR, given they create the file and are part of the same organization?

Hello @chuemb,
if you are still interested in getting this PR merged, please address the outstanding concerns above.
If not, I'll go ahead and close this PR.
Thanks!

I did not create the file, but @chuemb is part of our organisation, which should now also be publicly visible.

Hey Alexander,
thanks for your reply.

to process this request, please

create an account on http://accounts.jenkins.io/

=> We have a generic account "absint"

log in to Jira with the account created on accounts.jenkins.io:
https://issues.jenkins.io/

=> Logged into Jira with "absint"

log in to artifactory with the account created on
accounts.jenkins.io: https://repo.jenkins-ci.org/

=> logged into artifactory with "absint"

resolve the merge conflict
we need one of the existing maintainers to approve

It appears, the LDAP name is not an individual user but a GH org.
Possibly @bschommer https://github.com/bschommer could approve this
PR, given they create the file and are part of the same organization?

@bschommer recently approved me @chuemb as a part of the organization
AbsInt.
Furthermore, as he explained, @chuemb should be visible as a member of
AbsInt Organisation.
Is that sufficient for you to approve the PR?
Thanks and Best,
Christian

Christian Huembert
AbsInt Angewandte Informatik GmbH
Science Park 1
D-66123 Saarbruecken, Germany
@.***
Tel:   +49<PHONE_NUMBER>
Fax:   +49<PHONE_NUMBER>
WWW:http://www.absint.com
Geschaeftsfuehrung: Dr.-Ing. Christian Ferdinand
Registereintrag: HRB 11234 Amtsgericht Saarbruecken

Am 10.10.22 um 10:21 schrieb Alexander Brandes:

Hey @chuemb https://github.com/chuemb,
to process this request, please

create an account on http://accounts.jenkins.io/

log in to Jira with the account created on accounts.jenkins.io:
https://issues.jenkins.io/

log in to artifactory with the account created on
accounts.jenkins.io: https://repo.jenkins-ci.org/

resolve the merge conflict
we need one of the existing maintainers to approve

It appears, the LDAP name is not an individual user but a GH org.
Possibly @bschommer https://github.com/bschommer could approve this
PR, given they create the file and are part of the same organization?
—
Reply to this email directly, view it on GitHub
https://github.com/jenkins-infra/repository-permissions-updater/pull/2799#issuecomment-1272949980,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE6OATFNWSD6DKKC3FWTT53WCPGZPANCNFSM6AAAAAAQITTDDY.
You are receiving this because you were mentioned.Message ID:
@.***>

This PR adds a user with the ID chuemb to the permission file. This account needs to log in to artifactory and jira (links are above) in order to make the build pass.

I'll go ahead and close this PR, given the user you want to add didn't log into Jira and Artifactory within the past 6 months. Please have no hesitation to re-open the PR once this circumstance changes.
Thanks!


Make the images directory a constant

Extract images into /var/run/kmm/images.
/cc @yevgeny-shnaidman

/lgtm


make separate docker images of major node versions

mhart/alpine-node has various images for the versions of node available.
As you know, npm has different behaviour across versions.
Full install built with npm:

latest, 7, 7.4, 7.4.0 – 54.16 MB (npm 4.0.5)
6, 6.9, 6.9.3 – 49 MB (npm 3.10.10)
4, 4.7, 4.7.1 – 36.14 MB (npm 2.15.11)
0.12, 0.12.18 – 33.36 MB (npm 2.15.11)
0.10, 0.10.48 – 28.16 MB (npm 2.15.11)

Hi,
I updated the repo with branches by node-alpine tags and I added docker images tags by node-alpine tags .
I hope to receive your feedback

smashing sir! Testing it out now.

As far as I can tell, this ticket is solved. thanks!


Removal of test/debug code.

Removed main() method from LocalTemplateDownloader.java

LGTM

@borisroman I would like to see all the test-main removed as well but not without moving the actual test code into unit tests

@DaanHoogland True that. But then the discussion arises; until there are Unit Tests , do we keep this useless code?

Still looks good to me. pom.xml should be there

LGTM

Looks like what I meant @borisroman , LgreatTM


Question about dockerhub and rolling tag

Hello, congrat for the work.
I have a question about analysis on "rolling" tags like latest (or postgres 9.6).
When using postgres:9.6 in my cluster, I actually use postgres:9.6.17 (bad pactrice).
When postgres:9.6.18 is released, and the tags is updated, do Kubei scan the old postgres:9.6.17 as it is in use in my cluster or do it refer to 9.6.18 as it is referred by postgres:9.6 on the public registry ?

@mrhydejc, Thanks a lot for bringing it to our attention. This is indeed not best practice to use "rolling" tags and in this case the scan result will be for the new image in the registry instead of the actual image that is running. What would be the expected result in this case, to give a result for the running image and notify the user that a different image exists in the registry?

@akpsgit Notify the user that the image is outdated by comparing the sha256 digest sounds like a good idea.
Perhaps another solution can be considered with https://github.com/optiopay/klar/issues/153


Handle hidpi scaling.

The wording here is intentionally vague because I don't know very well what the possibilities are and what makes sens for winit. It is safe to say that it would be good for winit to expose some way to indicate whether the application is "dpi-aware" and avoid having the window upscaled by the window manager for apps that don't want this behavior.
On Fedora 25 with wayland (now enabled by default), winit windows are all upscaled on hidpi screens.
cc @vberger

I believe this needs some discussion, as DPI is not handled the same way on all platforms.
The wayland way is:

Each monitor has a scale factor, defaulting to 1.0, but it can be higher for HiDPI screens (typically 2.0)
Each window known on which monitor(s) it is displayed, and what their scale factor are
Each window draws in its buffer with the scale factor of its choice and notify the server about it (if not set, defaults to 1.0)
If the scale factors of the screen(s) and the one chosen by the application do not match, the server scales the contents of the window appropriately

From what I gathered, on Win32 each thread has a HiDPI-awareness level:

A window on a thread that is not HiDPI-aware (the default) will be scaled by the operating system.
A window on a thread that is HiDPI-aware is supposed to query the HiDPI level of the monitor and is assumed to be scaled based on this information. For example if you create a window of size 1280x1024 on a monitor that reports a resolution of 1280x1024 and a HiDPI level 2.0, the window will occupy half of the screen (and if the thread was not HiDPI-aware, the window would occupy the whole screen).
A window on a thread that is per-monitor-HiDPI-aware is the same as HiDPI-aware, except that it handles changing the current monitor itself. If you are only HiDPI-aware, Windows will automatically scale the window if you move it from one monitor to another that doesn't have the same HiDPI level. But if you are per-monitor-aware, it's the application that is responsible for this.

I couldn't find whether moving a window from a thread to another, or changing the HiDPI awareness level during the execution, modifies the existing windows. The HiDPI awareness is supposed to be set once at initialization.
The older way to deal with that was per application, and you could only set it once (all further calls would fail). Maybe this is also the case for threads.

We need to support 3 things to support high DPI:

Notifying OS that we are high DPI aware.
Getting scaling factor of the window. There is Window::hidpi_factor() function for this.
Receive notifications from the OS about change of the scale factor.

On Windows situation is as follows:
Notifying OS that we are high DPI aware

On Windows 10 Anniversary Update or later we can set DPI awareness individually for each created window:

Call SetThreadDpiAwarenessContext before creating the window.
Create window.
Restore DPI awareness of the thread by calling SetThreadDpiAwarenessContext again.

Quote from some unofficial documentation:

SetThreadDpiAwarenessContext() function was introduced in windows 10 aniversary update. This allows a thread to change its DPI awareness level at will, i.e. for some time duration a thread can set itself as DPI unaware, while at other times it cadn set itself as per monitor aware, or system aware. This allows the thread to create windows which have different DPI awareness levels. Using this we can build an application in which scaling of some UI elements is handled by windows, while scaling for others is handled by the application itself.

More info from the MSDN.

Windows 8.1 or later. DPI awareness is set for the entire process and can be set only once with the SetProcessDpiAwareness. If DPI awareness is set in the app manifest that value will take precedence and SetProcessDpiAwareness will fail.

On Windows Vista deprecated SetProcessDPIAware can be used.

Getting scaling factor of the window

Windows 10 - use GetDpiForWindow. It seems it was introduced in the Anniversary Update.

Windows 8.1 or later - use GetDpiForMonitor.

Windows Vista. Interestingly, there is a way to set DPI awareness on Windows Vista (SetProcessDPIAware) but I don't see a way to get the DPI value. WM_DPICHANGED is only sent on Windows 8.1. I checked all functions in the High DPI Reference and all functions for getting DPI are available only on 8.1 or newer.

Receive notifications from the OS about change of the scale factor
WM_DPICHANGED message is the way to go. It is sent by Windows 8.1 or later to DPI aware windows. It provides two values - X and Y DPI. MSDN says "the values of the X-axis and the Y-axis are identical for Windows apps". It is not clear why it explicitly mentions "Windows apps" as if there were some non Windows apps which could receive this message. I think for simplicity we can assume that they are always identical. I'm not sure which actions are required upon receiving this message. In MSDN they are calling SetWindowPos to change window size after receiving this message, I'm not sure why.

@kryptan That is because Windows 8.1 is where per monitor DPI awareness was added with support for changing DPI on the fly. For older Windows you can get the DPI by calling GetDeviceCaps with LOGPIXELSX and LOGPIXELSY.

Even on Windows 10 Anniversary Update it is still necessary to call SetProcessDpiAwareness to prevent Windows from scaling your app. If you only use SetThreadDpiAwarenessContext you will get both real values of DPI and scaling from the OS which leads to double scaling.
PR should be ready soon.

@kryptan For older Windows you can get the DPI by calling GetDeviceCaps with LOGPIXELSX and LOGPIXELSY.

It works but requires user to log out after changing scaling.

Yes, because older Windows only supports the notion of system DPI, not per monitor DPI, and changes to the system DPI require relogging. Regardless, that is the correct API to use for those older systems.

Currently Window::get_inner_size_points() invokes platform-specific code to get window size in virtual pixels while Window::get_inner_size_pixels() just multiplies this value by hidpi_factor. This means that platform backend needs to divide window size in real pixels by hidpi_factor and round that to integer while winit will then multiply it back. This logic should be switched, i.e winit should query platform backends for size in real pixels, otherwise we will get rounding errors. This requires changes to all backends.
For my Windows patch I will probably just follow the existing logic despite the rounding errors that it causes.

Aside from implementation details I'd like to raise the questions of what winit should assume from its users:

Are winit-based apps expected to always be hidpi-aware?

Thing is, as in wayland the user can bascially draw at any dpi they want, we need to be sure to advertize the proper used dpi factor to the server, other wise the sizes won't match.

Should it be per-program or per-window?
My current implementation for Windows is here. Windows has application global DPI-awareness. Latest Windows 10 has mechanism for per-window DPI-awareness but I hasn't been able to make it work. Setting awareness for window different from the global one causes weird issues. So my current implementation has one global function - become_hidpi_aware(). Nevertheless, other systems probably allow per-window DPI-awareness, so this should also need to be supported.

To move forward I think we need to agree on the cross-platform interface and then implement it in backends. This is kind of an RFC for the proposed API changes to winit.
Detailed design

Add become_hidpi_aware() global function. It will be implemented at least for Windows but may be a no-op on other platforms.

Add MonitorId::get_hidpi_factor() -> f32 method. This method is necessary to calclulate sizes of the windows that you will create.

Add WindowAttributes::hidpi_aware: bool field. This is a hint to the OS whether this new window should be scaled for high-DPI displays by the OS or by the applications itself. Note that at least on Windows we may not have control whether created window will be scaled by the OS or not so this is just a hint.

All methods in the Window struct should operate on physical pixels for high-DPI aware windows and on virtual pixels for high-DPI unaware windows. Namely get_position, set_position, get_inner_size, get_outer_size, set_inner_size, set_cursor_position. Otherwise we'll probably need to duplicate all of them like it is done for get_inner_size, and I don't see much need for this. Users can call Window::hidpi_factor() and calculate size in virtual pixels themselves if necessary.

Remove Window::get_inner_size_points and  Window::get_inner_size_pixels (replaced by Window::get_inner_size, see above).

Add WindowEvent::HiDPIFactorChanged(f32). This event will be executed when Window::hidpi_factor() changes. All backends must ensure that value passed to this event equals to the value returned from the Window::hidpi_factor().

All backends must ensure that for each window, either one of the following invariants holds:

Window::hidpi_factor() always returns 1 and all methods in Window are using virtual pixels (i.e. it is high-DPI unaware window, its content is scaled by the OS).
Window::hidpi_factor() returns real value and all methods in Window are using physical pixels (i.e. it is high-DPI aware window, its content must be scaled by the application).

Window::hidpi_factor() can be thought of as the scaling that is expected from the application.
Alternatives
Don't create become_hidpi_aware() global function, instead make application high-DPI aware when a window with WindowAttributes::hidpi_aware == true is created. The issue with this approach is that you want to know hidpi_factor before you create first window to correctly specify its size in pixels, but if we don't make process high-DPI aware on Windows then MonitorId::get_hidpi_factor() will always return 1 instead of real value.
Unresolved questions
Should we return bool from become_hidpi_aware() to indicate whether process has succesfully become high-DPI aware or already was? If we return bool should we always return true on platforms where it is a no-op?
What should be the default value for WindowAttributes::hidpi_aware?

Thoughts?

Is all the become_hidpi_aware functionality really necessary? For an application that doesn't care about it, wouldn't they just assume it's 1.0? I also wonder that, if we do need such a method, shouldn't it be a window builder method rather than a global?
The rest of this sounds good to me--both the MonitorId improvements and the additional event to the WindowEvent enum.

Is all the become_hidpi_aware functionality really necessary? For an application that doesn't care about it, wouldn't they just assume it's 1.0? I also wonder that, if we do need such a method, shouldn't it be a window builder method rather than a global?

If you don't care about it you just don't call it and assume that hidpi factor is 1.0. Whether it can be a builder method I think I addressed in the Alternatives section. By the time you create your window you already need to know hidpi factor to specify window size but to get it from MonitorId::get_hidpi_factor you need to make the process high-DPI aware first.

I may be wrong, but for me HiDPI awareness is just a thing that exists to preserve backward compatibility.
I don't think it's necessary to have a concept of not being HiDPI-aware.

@tomaka I agree with this but on Windows we can't just make process hidpi aware without consent of the programmer. Winit may be used as part of a larger application, e.g. in dll, where there are windows created by other, non-winit, code. Enabling high-dpi awareness will mess this up. Therefore, I think become_hidpi_aware() should be there.  On the other hand, WindowAttributes::hidpi_aware may not be necessary and we'll just attempt to make each window hidpi aware.

I have no concerns regarding wayland implementation, as wayland allows very fine control over dpi-awareness, we should be able to implement this API without much trouble.
However, I must say, I find it weird to have both a global become_dpi_aware() and a WindowAttributes::hidpi_aware. These just seem redundant.

Winit may be used as part of a larger application, e.g. in dll, where there are windows created by other, non-winit, code.

But this reasoning would also mean that these DLLs are forbidden to enable HiDPI-awareness as well, as they would mess up the rest of the application.
What I mean, is that more generally it's not possible to isolate a code that creates a window in its own little module or its own little library. Any code that creates a window (whether it is from winit or not) should specify what it does when it comes to HiDPI-awareness. Therefore I'd be in favour of making HiDPI-awareness mandatory for winit.

But this reasoning would also mean that these DLLs are forbidden to enable HiDPI-awareness as well, as they would mess up the rest of the application.

I have the following use case in mind. There is an existing C++ Windows application which has a GUI and which can use DLL plugins. These DLL plugins may need to display their own GUI to show user some settings. This is not just a theory, see e.g. #159. If the original application is not HiDPI aware then plugin written in Rust should not attempt to change that. This issue was previously raised here.

As an alternative we can provide an option to opt-out of the DPI-awareness in which case winit will not attempt to change any process-global settings.

I think I found a reasonable solution. The use case that I mentioned above is very niche while probably 99% of winit users on Windows are writing standalone executables where changing process-global settings is not an issue.
I propose the following: don't introduce become_hidpi_aware() global function and don't add WindowAttributes::hidpi_aware option, instead always enable high-DPI awareness when necessary (when monitor DPI is requested or window is created). For the niche use case when you are writing a DLL loaded by another process we can add a cargo feature which will prevent enabling DPI awareness on Windows. The only thing this feature would do is turning our internal function which enables DPI awareness into a no-op.

We'll also need to change MonitorId::get_position to return (i32, i32) instead of (u32, u32) because on Windows position can be negative. Primary monitor always has position (0, 0), if there is a monitor to the left or to the top of it then it will have negative position.

Can we consider this closed, given #319 and #324 are now merged?

@vberger Those PRs don't include the actual backend implementation of high DPI for Windows.

@vberger This is still largely unimplemented for most platforms.

Most platforms return hardcoded 1.0 from MonitorId::get_hidpi_factor()
No platform sends HiDPIFactorChanged event

Fair point.
Overall, I feel we need a clear way to track status of issues regarding both "public api design" and "backend implementation"...

On second thought, is the HiDPIFactorChanged event necessary? Wouldn't any change in high-DPI factor be also accompanied by the resize event? E.g. if high-DPI factor is changed from 1 to 2 then window size in pixels should also be increased by 2x and resize event will be sent. Maybe we should add information about high-DPI factor changes into the Resized event instead of adding a new event?

@kryptan Depending only on Resize event means, each time the event is fired, the client is expected to check Window::hidpi_factor() to see if it has changed. This is IMO not very ergonomic and easily error prone, while having the HiDPIFactorChanged event clearly hints that this is something that can occur and should be taken into account.
Alternatively, we could change the resized event from Resized(width, height) to Resized(width, height, hidpi_factor), this way all the information is present in a single event, while hinting clearly in the API that the client is expected to take hidpi into account.

@vberger That's what I meant. Although I think it is necessary to make it explicit whether hidpi_factor has actually changed. Either by adding bool or by making it an Option and using None if it hasn't changed.

I'd personally rather have the resize and dpi changed events be separate. After all, your Windows doesn't necessarily have to get resized by the window manager when the dpi changes.

Although I think it is necessary to make it explicit whether hidpi_factor has actually changed

In this case I think I prefer your original idea of having a HiDpiFactorChanged - I don't think checking a bool or Option in the Resized event would be quite as ergonomic. Perhaps we can ensure that each HiDpiFactorChanged event will always be immediately followed by a Resized event?

There's also the option of having HiDpiFactorChanged include the resize event's fields, though having two entirely separate events seems more likely to Just Work with simple client code.

your Windows doesn't necessarily have to get resized by the window manager when the dpi changes

My understanding is that it was decided that winit would alwaysreport as size of the window the actual pixel size of the drawing surface.
So if the dpi change, winit should resize the window to reflect that (preserving the pixel_dimension/hidpi_factor ratio constant). As such, a change in DPI will always trigger a resize event.

If they are separate events, wouldn't it be a problem that application may see inconsistent state - where one of the events was already received but not the other? If it uses some UI framework it may recalculate sizes of all widgets, and when second message is received it will need to recalculate them back.

Together with the DPI change notification Windows also sends the new suggested window size. In my PR I'm simply resizing window to this size. If I don't do this then this information will either be lost or need to be added to the HiDpiFactorChanged event.

Together with the DPI change notification Windows also sends the new suggested window size. In my PR I'm simply resizing window to this size. If I don't do this then this information will either be lost or need to be added to the HiDpiFactorChanged event.

In that case, I'd personally rather HiDpiFactorChanged  carry along the new suggested window size.

@retep998 Then it would also be necessary to introduce new method in Window. Windows gives us the RECT that can be passed directly to SetWindowPos but there is currently no method in Window which would directly call SetWindowPos with both position and size.
What would be the use-case where you don't want your window to be automatically scaled by winit?

I've made an OpenGL app to test high-DPI support. It should correctly handle high-DPI and respond to DPI changes.

Thanks @kryptan , this is very useful!

Okay, We still have an unresolved question regarding the HiDPI API.
The window creation api requires a size. Platforms such as wayland do not give you any way to know in advance which monitor your window will be created on. And if the user tries to guess the DPI from monitor list (like @kryptan 's example), but gets it wrong, winit will end up creating a gigantic or very small window.
The ideal process for window creation with wayland would be:

use specifies requested size assuming a 1.0 DPI
window is created with this size
once the window is created, it can check its actual DPI
if needed the user receives an appropriate HiDpiFactorChanged event followed by a Resized event with the dpi-aware actual size

How what do you think of this, and how would it be ok for other platforms? @tomaka @Ralith @mitchmindtree ?

Also @kryptan : I've tried using your app on linux, and it only displays a blue screen. Is that expected?

@vberger I've added screenshot to the readme. I've tested it only on Windows so it is possible that I accidentally relied on some platform-specific behaviour. Rendering is very simple, no idea what might have gone wrong.

Together with the DPI change notification Windows also sends the new suggested window size. In my PR I'm simply resizing window to this size. If I don't do this then this information will either be lost or need to be added to the HiDpiFactorChanged event.

In that case, I'd personally rather HiDpiFactorChanged carry along the new suggested window size.

Letting programmer to arbitrarily resize and reposition window in response to DPI changes can have an adverse effect of causing another DPI change. After reposition and resize Windows may decide that window is now back at the monitor it was moved from and fire another DPI change. As I understand this would also be an issue for the Wayland backend as well, because after resizing, window may not have intersection with the display that caused the original DPI change and Wayland backend would initiate another DPI change to restore DPI. This may cause infinite series of DPI changes. Microsoft has introduced the WM_GETDPISCALEDSIZE message to solve this and allow applications to specify their desired sized after DPI changes. Before changing DPI, Windows asks window what size it wants to be after DPI change and then calculates window position by itself.

Hmm, I'm not sure what you describe is relevant to wayland, which models DPI quite differently.
Basically, on wayland, each monitor has a DPI factor. And each app, when drawing, tells which DPI factor it is using. If the two don't match, the wayland compositor rescales the contents of the surface appropriately.
What winit would do then, is to always use the highest DPI among the monitors the window is displayed on. But while it would generate a Resize event to its user to notify the canvas size has changed along with the DPI, the actual window size as seen by the wayland server would not change.

@vberger there is no visible change in window size when you move it between monitors? If so then what I said probably doesn't apply to wayland and it is how I would want sane implementation of high-DPI to work. But on Windows when you move window between monitors it would appear normal on one monitor and gigantic or small on the other. Once move than half was moved, window is resized and looks normal on the new monitor but the part that is still on the previous monitor would become small or gigantic. In this case there is the actual window resizing and reposition caused by DPI change.

Yes, such behavior should not appear on wayland, as the compositor is expected to resize the contents appropriately. Also, wayland windows don't have access to their location anyway, so they don't know if/how they are being moved.

My earlier question about window creation is still pending and in my opinion a blocking matter for hidpi implementation. Thoughts @tomaka, @Ralith, @mitchmindtree, @kryptan ?

@vberger your proposal looks reasonable. It seems that macOS backend already works that way (#337). On Windows we'll need to create window with size in pixels, then get its DPI and then resize if necessary. At least I don't see any other way.
Also, I still think we should unify DPI change and resize events into one event to prevent application from observing inconsistent state. For example, my testing app will redraw everything twice on each DPI change - one time for the DPI change itself and one time for the associated resize, and the first redraw would actually be incorrect.

Was there a resolution on this? In #319, @kryptan added HiDPIFactorChanged(f32) event, which doesn't seem to capture the latest consensus on that event. In light of https://github.com/tomaka/winit/issues/105#issuecomment-343916767, specifically:

Also, I still think we should unify DPI change and resize events into one event to prevent application from observing inconsistent state. For example, my testing app will redraw everything twice on each DPI change - one time for the DPI change itself and one time for the associated resize, and the first redraw would actually be incorrect.

It seems like another way to handle this is to keep them as separate events, include Option(Resized) in the HiDPIFactorChanged event, and only fire HiDPIFactorChanged even if there is a resize, if it's due to the dpi changing.

Ok, I did some testing and actually that might be tricky for macos backend since a resize event is sent when the display resolution changes.
It still seems like the HiDPIFactorChanged event should include a Resized, though?

I'm gonna go ahead with a PR with the signature, it should be pretty easy to change later.

@vberger the way things are implemented in #332, the window is automatically resized and repositioned whenever the DPI changes, since Windows conveniently sends us the recommended geometry when that happens. Is this something you believe should be handled by the application developer instead?

@francesca64 No, I agree this is good to handle it automatically.
My only point of question is on the window creation API: when the user defines the size of their newly created window, they cannot anticipate on which monitor this window will appear (or can they? At least not on Wayland).
As such, it seems weird to specify this size in physical pixels, as this would require in advance to know the DPI factor of the monitor on which the window will appear.
This is why my suggestion was to instead always initially set this size in "logical pixels" (by this I mean assuming a DPI factor of 1), and then receive the proper HiDPI instructions from the server and forward them to the app via the appropriate events to let it handle it correctly.

@vberger well, I already have it so that it sends a HiDPIFactorChanged and Resized after window creation if the DPI factor turns out not to be 1.0, since that seems to be the idea. Outside of specifying which monitor to put the window on, I don't believe we can get this info in advance on Windows either.

As such, it seems weird to specify this size in physical pixels, as this would require in advance to know the DPI factor of the monitor on which the window will appear.
This is why my suggestion was to instead always initially set this size in "logical pixels" (by this I mean assuming a DPI factor of 1)

Okay, I'm definitely confused now. I thought we were specifically trying to use physical pixels. So, inferring from this, am I now correct in understanding that (with HiDPI) a 100x100 physical pixel area isn't 100x100 usable pixels we can render to, but instead gives us as many usable pixels as are represented by 100x100 pixels in the monitor? I was under the impression that 100x100 physical pixels would give us 100x100 usable pixels, but just not in the desired scale.

There's three kinds of pixels:

Physical pixels or display pixels. The actual pixels on your monitor.
Application pixels or framebuffer pixels. These are the pixels you render too and with high dpi support they usually correspond to physical pixels but if your application overlaps multiple displays then they might not.
Logical pixels. This is an arbitrary system of measurement based on how big pixels are on a standard dpi display and adjusted based on user dpi preferences. Unless you are on a standard dpi display with no dpi scaling, logical pixels do not correspond to actual pixels. Do all your measurement and sizing in logical pixels, which are converted to and from application pixels when rendering and handling input.

Setting the size of a window when creating it should absolutely be done in logical pixels, partially because you might not know what dpi the window will be at until created and partially because that's what you want 99% of the time anyway.

Wouldn't this lead to loss of precision?

I don't think so, given winit reports pointer location as f64, and I don't think the possible DPI factors are large enough that this would cause a loss of precision.
The interest in processing input using logical pixels is that it allows winit users to only have to care about HiDPI when drawing, but not when processing input, as whatever the DPI your drawing for, the size and location of your UI relative to the dimensions of your window will likely be the same.

@francesca64

Wouldn't that be a breaking change, and one that people are unlikely to catch?

It depends on what the different backends currently do I guess. Indeed if there is already an existing uniformity we should stick to it. If not, it would be a good opportunity to design it.
Wayland currently does not handle DPI scaling at all yet, meaning that everything is always in logical pixels (the server handles the rescaling for us). Apparently Window is horribly broken as you said. What do the MacOS and X11 backends do?

Also, isn't creating a window in logical pixels with an assumed DPI factor of 1.0 the same as using physical pixels (assuming the entire window is on one monitor)? That's another thing I've been confused about.

Well, my understanding is that (please someone correct me if I'm wrong):

if we create a window by specifying physical pixels, the requested size must take HiDPI into account. For example, if the window would be 100x100 on a 1.0 scaling output, but we are being displayed on a 2.0 scaling output, we need to ask for a 200x200 window, or else the window will be twice too small.
if we create a window by specifying logical pixels, we ask for a 100x100 window. Then later the backend sends us an event telling "wait, you are actually displayed on a 2.0 scaling output, and thus should draw on a 200x200 window", and we can adapt to that.

At this point, it quite depends on what the system APIs do. The Wayland one is really oriented towards the first case, as almost everything is done in logical pixels.

@vberger MacOS and X11 both give physical pixels, and after skimming through search results on GitHub it seems to be pretty universally assumed that winit gives values in physical pixels as well. Because of that, I don't think it's feasible to switch over to logical pixels at this point.
It doesn't seem like a good idea create an API where window creation is done in logical pixels while everything else is done in logical pixels, because of the issues with API inconsistency. One option we have to handle that is to have the user explicitly request that the window size be in physical or logical pixels at creation, then have everything else assume physical pixels. The main ways I can think of to do that would be to either split the window-size functions into with_dimensions_physical/with_dimensions_logical or to have with_dimensions take an enum that specifies which kind of size the user wants.

it seems to be pretty universally assumed that winit gives values in physical pixels as well

Alright, the question is closed then. :)
Re @ creation dimensions: I still fail to see how it is possible to specify a creation size in physical pixels in a meaningful way.
For example, image a setup with two monitors, one has a dpi factor of 1.0, the other of 2.0.
A user tells winit they wand a 100x100 physical pixels window.
What should winit do? Is it a 100x100 pixels window on the 1.0 screen, that will be rescaled to 200x200 when moved to the 2.0 one, or a 100x100 pixels window on the 1.0 screen, that will be rescaled to 50x50 when moved on the 1.0 one?

@vberger I think I understand now. Up until this point, my thought process was "but isn't specifying logical pixels for 1.0 the same as specifying physical pixels?" but what you want is for the window creation size to semantically be the logical base size of the window.
Oh, right, and since you mentioned sending Resized before, the idea is for the backend to automatically resize the window after creation if the DPI isn't 1.0, right? This makes a lot of sense now. I was just sending Resized without actually resizing the window, which seems to be a symptom of working on winit without taking enough breaks.

@francesca64

but what you want is for the window creation size to semantically be the logical base size of the window.

Yes, that's it. Sorry if that wasn't clear before.

the idea is for the backend to automatically resize the window after creation if the DPI isn't 1.0, right

That is indeed my understanding of what is done. On wayland, the client can choose at which scaling factor it is drawing and the server rescales the content if necessary, that's why everything else is done in logical pixels in the protocol.
Thus, what I'm doing in #341 is that each window tracks the list of monitors it is currently being visible on, and sets its DPI factor as being the highest of them all. Thus, every time the window enters or leaves a monitor, the backend computes the new appropriate DPI factor, and if it changed, generates a Resized() event and a HiDPIFactorChanged() event with the appropriate values. I don't actually resize the window as this is not handled by winit itself due to how wayland works, but the user (glutin for example) will automatically handle it when processing the Resized() event.

@vberger I've gotten sidetracked by completely replacing the keyboard handling in the macOS backend, since things like that happen whenever I have to review a PR on another platform. However, I thought it would be a good idea to look into sorting out HiDPI on X11 before moving forward here, since I can make sure X11 is consistent with macOS and Windows, and then you can make sure X11 is consistent with Wayland.
So far it's been easier than expected. #515 contained much of the groundwork, and the only major obstacle left is figuring out why I can't get XResizeWindow to work when moving to another monitor. My hypothesis is that my WM's window snapping is interfering, but I digress... if I'm understanding your point about using logical pixels for input handling correctly, then it sounds like a good idea, and I don't anticipate this taking much longer to wrap up.

@francesca64

if I'm understanding your point about using logical pixels for input handling correctly, then it sounds like a good idea, and I don't anticipate this taking much longer to wrap up.

Hmm, didn't we conclude that as winit is basically already physical pixels everywhere, this should be kept as-is?
An other point to be careful on, when mixing physical and logical pixels, is that we can't go all the way logical, the client still needs to know the size of its actual drawing surface. So there would be a need to distribute it accordingly (modifying the Resize event to provide both physical & logical size?), or explicitly document that the drawing surface dimensions is always logical dimensions times dpi scale factor?

Since it seems likely that both logical and physical pixels will be part of the API, how about introducing a named type for each, instead of anonymous tuples? I will gladly take a broken build every time over runtime errors.

@anderejd Well, that sure is a good idea.
We could go all the way with something like:
#[derive(Copy, Clone)]
struct Coordinates { x: f64, y: f64}

impl Coordinates {
    pub fn from_logical(x: f64, y: f64) -> Coordinates {
        Coordinates { x, y }
    }
    pub fn from_physical(x: f64, y: f64, dpi_factor: f64) -> Coordinates {
        Coordinates { x: x/dpi_factor, y: y/dpi_factor }
    }
    pub fn to_logical(&self) -> (f64, f64) {
        (self.x, self.y)
    }
    pub fn to_physical(&self, dpi_factor: f64) -> (f64, f64) {
        (self.x * dpi_factor, self.y * dpi_factor)
    }
}

and use that type everywhere, letting the user use what they prefer. This would also make clear that physical coordinates are only meaningful in the context of a dpi factor.

@vberger sounds like a plan! Would it be good for that struct to contain the DPI factor as well?

Tbh I'm not quite sure. The risk of storing the DPI factor in it would be a user keeping an old Coordinates value around, and then trying to use it while the actual dpi factor changed in between, and gets invalid results due to that.
Keeping it out would make clear that the DPI factor is some context value that may change and needs to be tracked, I guess.
On the other hand, integrating the DPI factor in the struct is certainly more convenient if we assume that there are supposed to always be short-lived anyway.

That risk sounds like it's largely mitigated by the existence of HiDPIFactorChanged.

Yeah, but in that case I think we need to make it very clear that the Coordinates objects are created for a given dpi, and that a DPI change would invalidate them (and add an API to update them to a new DPI, I guess).

I think I'm still in favor of including it, since when possible users should favor responding to events over directly querying things, and I think they're more likely to follow that recommendation if the DPI is included.
(I'm assuming you agree with that recommendation. It's partially motivated by our inability to guarantee that queries will always have a low cost.)

It's partially motivated by our inability to guarantee that queries will always have a low cost.

Wouldn't that be a strong argument to not build an API that forces the backends to make such queries on every event with a coordinate in it? I'd think the queries could be made cheap just by caching the latest value for each window, though.
There's also the downside that anyone who is going to be passing around or storing lots of logical coordinates (say, for a GUI impl) will need to come up with their own type and do a lot of converting.

@Ralith true, the performance issue was a weak argument on my part. Why would including the DPI factor in the struct force application developers to make their own type and do lots of converting, though?

Because if the DPI factor is embedded, the struct is larger than necessary for performing computations purely in logical space, which is undesirable. People could just ignore the cost, but it's an incentive against using it all the same.

How do you handle the coordinate object having an embedded dpi factor when the window is overlapping multiple displays with different dpi factors on each?

The idea I was thinking of regarding named types instead of tuples was something more like this:
struct LogicalCoordinates { x: f64, y: f64}

struct PhysicalCoordinates { x: f64, y: f64}

With the primary purpose of not mixing them up, if we need both in the API.
I'm unsure if the DPI factor should be bundled with the coordinates or not.

@anderejd sounds good to me. It's simple, composable, clearly communicates the intentions, and provides us with more hope for getting this done before this issue hits 100 comments.

For the record: my suggestion was voluntarily going farther than yours @anderejd , I was just thinking that in APIs where there is no obvious "better choice" between them (which may be many), offering an abstraction over both could be useful.
Nevertheless, this can easily be done with your suggestion as well, by adding appropriates .to_physical(dpi) and .to_logical(dpi) methods to these types.
So, from my point of view both are pretty equivalent, I don't have any strong preference between any of the two approaches.

So, which functions should take/return logical pixels, besides with_dimensions (and presumably with_max_dimensions and with_min_dimensions)?

That seems reasonable based on what has been written earlier in this issue, @vberger ?

Option 2 makes more sense to me. Making drawing special probably makes more sense to the average user than making window creation special.
Either way, besides API documentation, I think we really ought to have an example program for this. I'm not sure where it should live (since without a drawing surface there's nothing to demonstrate) but I'm confident it would improve the chances of people actually supporting HiDPI.

I believe it was stated a few times that winit would explicitly not support non-dpi aware apps...
Furthermore, using the logical/physical pixels wrapping structs should make it rather difficult to accidentally be non-dpi aware, wouldn't it?

Alright, PR is up: #548


Dev/shgu/crlf fix

Repro Steps:

Using vstest.console.exe, user runs a test which has Trace.Writeline() statement with some line breaks, and generates a trx file
Open the trx file in Visual Studio
Select the test result, right click --> View Test Results Details

Result: In the Results window, check the ‘Standard Console Output section’. Notice that the text is present in a single line and not in multiple lines.
Issue: Carriage Return character is not getting retained while generating TRX file
Fix: In TrxLogger, PopulateTrxFile(), while saving the file use XmlWriter and in its settings, specify NewLineHandling.Entitize option

@dotnet-bot retest Windows_NT / Release Build please


Write a blog post about the new identity and website

@doublejess Send me the title and content and I will add it to the article_mixit.json file.

Maybe we should keep this open until the actual article is embedded in the website.
https://paper.dropbox.com/doc/Une-nouvelle-identit-pour-MiXiT-SIo5dZ5p7Gn2ZJRcIhFJD
Assigned to @sdeleuze.

Will (try to) do it, if @sdeleuze is not already on it.

I am not on it and that would really help, thanks @clacote !


net/http: DefaultServeMux incorrectly redirect (301) to path if path includes %2F%2F

What version of Go are you using (go version)?
go version go1.9 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/kalbasit/code/personal/base"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build643957992=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?
package main

import "net/http"

func main() {
	http.ListenAndServe(":8878", nil)
}

curl 'http://localhost:8878/path:a%2F%2Fgoogle.com%2F'

What did you expect to see?
404 page not found
What did you see instead?
Moved Permanently.
NOTE: this does not happen if alice was used instead of the http.DefaultServeMux

FWIW it happens even with http://localhost:8878//, the key aspect being two consecutive /s.

Redirecting http://localhost:8878// to http://localhost:8878/ is correct.
But redirecting http://localhost:8878/%2F to http://localhost:8878/ is not correct.
I think this is a bug to be fixed.

CC @bradfitz @tombergan

I fixed similar bug in the past, so I will confirm this.

I'm not sure if this actually a bug in the first place. The URL reported in the original comment is:
http://localhost:8878/path:a%2F%2Fgoogle.com%2F

The decoded path is:
/path:a//google.com/

That path clearly has a double slash and path.Clean translates double slashes to single slashes. Also see here. The godoc for ServerMuex.Handler says:
// If the path is not in its canonical form, the
// handler will be an internally-generated handler that redirects
// to the canonical path.

If there's an open question here, the question is around the definition of "canonical path". Does the canonical path convert double slashes to single slashes? If so, there's no bug. If not, there's a bug. AFAICT, this question is not answered anywhere. In net/http/server_tests.go, serverMuxTests does not have a case for double slashes, so I suspect this question hasn't come up until now.

@tombergan Thank you for the clear explanation. I'll investigate this problem again.

@tombergan @bradfitz
As a countermeasure against this similar problem, there is nginx merge_slashes syntax.
Even with nginx, the above options are used for cases where you do not want to integrate encoded duplicate slashes into one.
And then, I have take a look at RFC-3986 for confirming the encoded double slashes validity.
According to it, the encoded string pchar is considered valid.
   path          = path-abempty    ; begins with "/" or is empty
                 / path-absolute   ; begins with "/" but not "//"
                 / path-noscheme   ; begins with a non-colon segment
                 / path-rootless   ; begins with a segment
                 / path-empty      ; zero characters

   path-abempty  = *( "/" segment )
   path-absolute = "/" [ segment-nz *( "/" segment ) ]
   path-noscheme = segment-nz-nc *( "/" segment )
   path-rootless = segment-nz *( "/" segment )
   path-empty    = 0<pchar>

   segment       = *pchar
   segment-nz    = 1*pchar
   segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                 ; non-zero-length segment without any colon ":"

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   query         = *( pchar / "/" / "?" )

   fragment      = *( pchar / "/" / "?" )

   pct-encoded   = "%" HEXDIG HEXDIG

Therefore, I think, if we follow RFC-3986, the current behavior is buggy.

@bradfitz ping? If my survey is reasonable, I'm going to try to improve the patch based on this survey result.
Do you have any opinion?

@bradfitz @tombergan ping?

To expand on @tombergan's comment (https://github.com/golang/go/issues/21955#issuecomment-379057478), the ServeMux documentation states:

ServeMux also takes care of sanitizing the URL request path and the Host header, stripping the port number and redirecting any request containing . or .. elements or repeated slashes to an equivalent, cleaner URL.

The documentation is not explicit on whether %2f is considered a slash, but the implementation consistently treats it as such. ServeMux.Handle("/foo/", f) matches the request /foo%2fbar.
I believe the current behavior is consistent with the documentation and probably can't be changed without violating compatibility. Perhaps the documentation should explicitly mention the treatment of escaped path components.

I'm suffering the same problem trying to use an encoded full URL in the path.
For example I'm trying to use this URL (an image from Wikimedia):
https://upload.wikimedia.org/wikipedia/commons/4/49/Mosuo_Woman_-_42723465920.jpg

Once encoded we get the following URL:
https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F4%2F49%2FMosuo_Woman_-_42723465920.jpg

And this is the request to my server using the previous URL as path:
http://localhost:8080/https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F4%2F49%2FMosuo_Woman_-_42723465920.jpg

I'm receiving a 301 status code with a Moved Permanently body message linking to:
http://localhost:8080/https:/upload.wikimedia.org/wikipedia/commons/4/49/Mosuo_Woman_-_42723465920.jpg?w=500&h=500&fm=png

I understand that ServeMux is cleaning paths and redirecting in the case of differences but what I don't understand it's why that is done for escaped characters like %2F%2F.
Apart from the possible bug, anybody knows any solution/workaround that doesn't involve creating from scratch a custom serve mux or using another one available? Any possible way to avoid that cleaning?

This is clearly a bug.
The encoding method can encode arbitrary data in a Uniform Resource Identifier (URI), which is the point of the encoding.
"/" is the reserved character slash. "%2f" is an arbitrary string.
"/" and "%2f" are two different things.
Is "%2f" is a slash?
No, of course it is not a slash. and "%25" is not a percent sign
Otherwise "https://www.google.com/" will be equivalent to "https:%252f%252525252fwww.google.com%2f".

Just faced this issue in the latest go 1.18.3
curl http://localhost/%2Fhello is decoded internally to //hello (r.URL.Path) and the decision for a 301 redirect based on r.URL.Path instead of r.URL.RawPath.
A dirty hack that fixed useless 301 redirect issue for me:
--- go/src/net/http/server.go   2022-06-01 18:44:51.000000000 +0200
+++ go_/src/net/http/server.go  2022-06-15 23:44:02.602151436 +0200
@@ -2412,7 +2412,7 @@
        // All other requests have any port stripped and path cleaned
        // before passing to mux.handler.
        host := stripHostPort(r.Host)
-       path := cleanPath(r.URL.Path)
+       path := cleanPath(r.URL.RawPath)

        // If the given path is /tree and its handler is not registered,
        // redirect for /tree/.
@@ -2420,7 +2420,7 @@
                return RedirectHandler(u.String(), StatusMovedPermanently), u.Path
        }

-       if path != r.URL.Path {
+       if path != r.URL.RawPath {
                _, pattern = mux.handler(host, path)
                u := &url.URL{Path: path, RawQuery: r.URL.RawQuery}
                return RedirectHandler(u.String(), StatusMovedPermanently), pattern


Default width of NumberField is different from TextField default width

@JohannesLaidler commented on Mon Apr 08 2019
Description
Default width of NumberField is different from TextField default width
Expected outcome
Width of NumberField should be the same as TextField width, if no width is explicitly set.
Actual outcome

Example
@Route("test")
public class VaadinTest extends VerticalLayout {

    public VaadinTest() {
        add(new NumberField("NumberField"), new TextField("TextField"));
    }
}

Versions

Vaadin / Flow version 13.0.1
Java version jdk-11.0.2
OS version Windows 10
Browser version Google Chrome Version 73.0.3683.103 (64-Bit)

@ZheSun88 commented on Tue Apr 09 2019
Issue moved to webcomponent repo

The number-field width is indeed different.
https://github.com/vaadin/vaadin-text-field/blob/1ee12ce01da1de3fdbc551fc06d0e4ff89088fa5/theme/lumo/vaadin-number-field-styles.html#L9
I don't really remember based on what it was chosen to use 8em. It probably makes more sense when using controls, but the width is anyways opinionated. We could consider dropping it.

bumping this issue, as it would greatly help to have it fixed


Cherry pick 5749 & Release v2.11.1

This cherry-picks #5749, and cuts v2.11.1 including it.
@brian-brazil @simonpasquier @krasi-georgiev @beorn7 @gouthamve @cstyan @juliusv @codesome

:+1:


🌐 Add Chinese translation for docs/advanced/security/index.md

as title

It seems this was translated at some point in another PR. So I'll close this one, but thanks for the effort! ☕


Problem with Discourse extractor?

Hey @mikwielgus thanks for this project as I have been looking for a way to crawl a large Discourse site. Having the below problem and not sure if it is a Python bug or PEBCAK.
python3.10 -m pip install forum-dl
forum-dl "https://community.example.com/" -o ~/Downloads/community.jsonl --textify -f jsonl

{
    "generator": "forum-dl",
    "version": "0.1.0",
    "extractor": "discourse",
    "download_time": "2023-05-21T22:32:10.732919+00:00",
    "type": "post",
    "item": {
        "path": [
            "1",
            "12973"
        ],
        "url": "https://community.example.com/t/slug/<built-in function id>",
        "origin": "https://community.example.com/t/slug/12973.json",
...

The issue is that the URL has <built-in function id> after the topic slug instead of the item path/id. I guess it has to do with this line which appears to clash with the built-in Python id function...

Yeah, I need to using id as a variable name, it's bug-prone.

Thanks for the patch. I've renamed all the variables named id to something else in 8d691e24f67a6851aef99370318e10dd80df005d just now.


Optgroup feature

Is it possible to realize  feature in Dropdown or Autocomplete component with react-toolbox?

It will come with a future version. I have another Dropdown implementation when this is done but it's blocked until the PostCSS version is officially out.

Would be great to have this one. Currently we are extending unthemed Autocomplete, kicking in groups in renderSuggestions() and wrapping theme.

Closed in favor of #1030

I might be wrong but seems #1030 is a different one?

I meant #1169 😅


KafkaStreamsConfiguration Conversion

Add ConversionService to convert map values to String.
Also use Class.getName().

Do not merge. Must not mutate shared instance


Tink state fails to compile with haxe 4.2

Tink state fails to compile with haxe 4.2
/tink_state/0.11.1/haxelib/src/tink/state/Promised.hx:15: characters 7-34 : error: Dynamic should be next.B /tink_state/0.11.1/haxelib/src/tink/state/Promised.hx:15: characters 7-34 : ... have: tink.core.Promise<Dynamic> /tink_state/0.11.1/haxelib/src/tink/state/Promised.hx:15: characters 7-34 : ... want: tink.Promise<next.B> /tink_state/0.11.1/haxelib/src/tink/state/Observable.hx:71: characters 34-41 : Invalid call to static function flatten through abstract instance
To be able to compile you must use haxe 4.1

I've upgraded tink_core and tink_state to github versions, it seems to work for Haxe 4.0-4.2.
it doesn't work for Haxe 3 and also not for nightlies (which is probably a little bit concerning; maybe test locally and potentially raise an issue).
if there is a combination of versions or branches that works better, let me know and I will install them.

I guess it works, so I'm closing the issue. feel free to reopen.