bug(ast): AccessMember should check for undefined and null

The AST evaluation for AccessMember can break if the member is undefined rather than null.

Fixed in 68ab50738e1a77b23bff96a86c1f017d9c39f91b


Handle simple object template

Look for the object template for simple (aka non folders) objects.

It should already look for objects.twig or objects.ctp. Do we want it in the singular form "object"?

It should already look for objects.twig or objects.ctp. Do we want it in the singular form "object"?


⚠ ClamAV has degraded performance

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

HTTP code: 200
Response time: 443 ms

Resolved: ClamAV performance has improved in 1ee2340.


added text_sectors script

I created a text_sectors script with getters for the outputs of the text clustering (i.e. ClusterGlass flow).
For now this only includes functions to get text_sectors and topsbm_models but going forward it could also include getters for reassigned text sectors etc.

Checklist:

[x] I have refactored my code out from notebooks/
[x] I have run flake8 and addressed any linter erors
[x] I have checked the code runs
[ ] I have tested the code
[x] I have run pre-commit and addressed any issues not automatically fixed
[ ] I have rebased onto dev (or merged any new changes from dev)
[x] I have documented the code

[ ] Major functions have docstrings
[ ] Appropriate information has been added to READMEs

[x] I have explained the feature in this PR or (better) in output/reports/
[x] I have requested a code review

Addressed both comments.


The Pagination widget can generate wrong URLs

For instance with page=-1. I'll disable the URL generation if isDisabled.

how was the bug triggered (what usage led to the bug?). How can I reproduce it?

how was the bug triggered (what usage led to the bug?). How can I reproduce it?

Check the link that is generated on the "«" previous button when you're already on the first page.


How to not use es5

The bug around iterator abrupt termination in loose mode confirms (and makes worse) what we already knew: the library kind of sucks when transpiled to es5. End users who don't need IE support can work around this easily enough by including the /es2015 paths, but that's 1) a pain, and 2) doesn't work if the including entity is itself another library.
I think the solution is to write a plugin of some sort. I'm taking some inspiration here from babel-plugin-use-lodash-es.
Actually a Babel plugin won't work for us because projects are responsible for their own transpilation and thus a library including iter-tools would have to do what we do and output multiple complete copies of their source files and allow the user to choose between them.
A webpack plugin, however, makes a lot of sense. The bundler already goes deep into the module tree. It could look at a a project's browserslist as specified in package.json, then rewrite imports to include the highest supported version of the files. Libraries would statically include the es5 modules, but those includes would be resolved to the es2015 files if supported. This makes the assumption that if the more transpiled code works correctly in a given situation, the less transpiled code will too (as long as browserslist feature detection isn't lying). Of course users wouldn't be required to use the plugin either, but it'd be quite nice.

The situation with third party imports is messed up.
I think if you are building a library, the only sane solution is to use iter-tools/es2018 and to transpile in your library. It is horrible but I don't know what else you can do.

No activities here for too long. Closing


Update form widget doc

@Pranay105 - I've updated Gitbook for form widget. Please review.

@cokoghenun - Could you please add the ticket to update the video?

I'll do that @jnikhila

Closing since this looks like updated

@Rishabhkaul - Reopening as we need an updated video for this. @cokoghenun - Could you please confirm the ETA for this?

This is still on my list because of other high-priority stuff. I'll work on it and raise a PR, but we can close this issue in the mean time


Waypoint/zTunnel L4 Authz Policy Edge Case

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Today when a waypoint exists the ztunnel does not enforce authz policies.
However, the authz policies with/without waypoint have different selectors:
L4 authz policy without a waypoint:
selector:
    matchLabels:
      app: helloworld

L4/L7 authz policy with a waypoint:
selector:
    matchLabels:
      istio.io/gateway-name: helloworld

This difference in the selector raises problematic edge cases where user has a L4 authz policy (without a waypoint) and deploys a waypoint. In this case the existing authz policy isn't enforced by the waypoint.
Version
1.19.0

Additional Information
No response

Thanks @keithmattix!
Just trying to understand how the layer-targeted authz doc will cover this, would I specify
layer: UNSET
or not specify any layer (given default behavior is UNSET) in my authz policy to ensure the authz policy can be enforced as I add a waypoint and without any change to authz policy?

Or there is no way to not change my Authz policy as I add a waypoint?

ztunnel does not enforce UNSET policies per the doc. User would specify that their policy is layer: TRANSPORT before adding the waypoint and the ztunnel will enforce it. Once the waypoint is added,  both the waypoint and the ztunnel can enforce it, depending on whether the request is hairpinned or not (hairpin = ztunnel enforced, authed = waypoint enforced OR double enforcement)

So adding the layer stuff would remove the "ztunnel enforces your policy until a waypoint is deployed at which point it silently stops enforcing" problem by saying that ztunnel will never enforce policy unless it has a L4 target explicitly, so there's no conditional enforcement anymore.
Got it.

Issue has been presented in the Ambient weekly meeting (September 27th, 2023 / Recording) and led to a broader discussion around this and similar issue with current design.

Update: @louiscryan and @howardjohn is leading a design doc to re-design how authz should work and make it consistently when moving from L4 to L7.

Not stale.

Need to validate this - believe this should be taken care of based on the proper status of Authz policy to warn users.


Graduate LendingLimit to Beta

What type of PR is this?

/kind feature
What this PR does / why we need it:
Graduate LendingLimit feature to beta and enable it by default.
Feature flag is now enabled by default also in the tests. Added new test cases to verify a cases when LendingLimit field is set without a feature flag enabled.
Which issue(s) this PR fixes:

Special notes for your reviewer:
Does this PR introduce a user-facing change?

Graduated LendingLimit to Beta and enabled by default.

/kind feature
/cc @alculquicondor @gabesaba @kerthcet

/lgtm
Thanks for promoting this. Once we can remove the false branch in 0.10, the codebase will be easier to understand/read :)

Got that, thanks for the work @macsko


PL/* language packages are not installed

The http://apt.postgresql.org provides packages like postgresql-plperl, postgresql-plpython, postgresql-plpython3 and postgresql-pltcl for them.
I think, they should be installed alongside with postgresql-contrib, otherwise you'll get an error like
PG::UndefinedFile: ERROR:  could not open extension control file "/usr/share/postgresql/
9.3/extension/plperl.control": No such file or directory
:       CREATE EXTENSION IF NOT EXISTS plperl

when you'll encounter the app that uses the one of PL/* languages for whatever reason.
I'm having this issue with PL/Perl and Dockerfile for 9.3 but there are also packages for 9.4 and 9.5.

im struggling with this as well!  did you come to any conclusion?
alpine doesn't ship a plpython for postgres 9.5.x/9.5.10, and im struggling to find documentation on how to load it.
i even downloaded the 9.5 source and compiled it, but still not clear which artifacts are relevant and where they go!

whoops, i commented in the wrong issue.  this issue is essentially closed (rejected) w/ the closure of #115

I'm closing this, as reasoned by the above comments.


Implemented shadow on UWP

Description of Change
Well, I've implemented this effect via DropShadow (next DS). But DS has strange behavior. DS appears above the element and I decided to pack an element to StackLayout.
This StackLayout has a structure:
StackLayout
> Grid (For shadow)
> Element
After these changes I appended shadow to Grid, and it's working :)
Maybe my solution isn't very good, but I think we have just one way to implement shadow on UWP.
Bugs Fixed

Fixes #847

API Changes
None
Behavioral Changes
None
PR Checklist

[ ] Has tests (if omitted, state reason in description)
[ ] Has samples (if omitted, state reason in description)
[ ] Rebased on top of main at time of PR
[x] Changes adhere to coding standard
[ ] Updated documentation

Screenshot

@sattew thanks for this PR! Is good to see some love to UWP. Well I've some suggestions and questions for you.
Also I see that you wrap the content inside another layout (stack or grid) but when the use detaches the effect we don't revert that, we're adding more elements in the visual tree and that's bad for perf. So I would ask.
1. Can we use another approach? I mean on top of your head do you know another thing that we can do?

2. If you answer "no" for the previous question. Can we remove the extra layout on `OnDettached` method?

I have no idea how we can do this any other way. Use ThemeShadow but this shadow doesn't have props to control (color, blur etc.)
Yes, we can remove extra layout, but it means we need to change page's structure again and we can lose in performance, I gues. For example if we have a lot of elements with shadow (In CollectionView or something else) and there will be a lot of operations to set the parent.

I have no idea how we can do this any other way. Use ThemeShadow but this shadow doesn't have props to control (color, blur etc.)

Yes, we can remove extra layout, but it means we need to change page's structure again and we can lose in performance, I gues. For example if we have a lot of elements with shadow (In CollectionView or something else) and there will be a lot of operations to set the parent.

Yeah... you have a good point here on 2, so let's assume that if someone wants shadow, that person will not remove it during the usage, like something dynamic. I believe that we can do move forward with this implementation and see how it goes.

I have no idea how we can do this any other way. Use ThemeShadow but this shadow doesn't have props to control (color, blur etc.)

1. Yes, we can remove extra layout, but it means we need to change page's structure again and we can lose in performance, I gues. For example if we have a lot of elements with shadow (In CollectionView or something else) and there will be a lot of operations to set the parent.

Yeah... you have a good point here on 2, so let's assume that if someone wants shadow, that person will not remove it during the usage, like something dynamic. I believe that we can do move forward with this implementation and see how it goes.

let me some time also, I want to check one thing about question 1.

Yeah. I checked again one thing and it's not working. I tried to add shadow to current parrent of element. But the shadow is still above element. Not working.


Add config to global namespace

Don't mixin configs to modules in /lib and /domain.
Now we can access configs by: config.name.key.
Closes: https://github.com/metarhia/impress/issues/1316

Landed in https://github.com/metarhia/impress/commit/6196c25c692da4e6a6b2820ff0065a881cf68df1


Search bar layout broken on smaller viewports

I'm assuming this is due to the update to the menu that was just pushed live. It's not completely broken as when the viewport gets smaller it readjusts to the correct positioning. But there's a small window where it's broken.

FYI @molant
If I have time this afternoon, I'll look into it. I can't remember where exactly in the code this is.

navigation.css I believe is the right place.
https://github.com/webhintio/webhint.io/commit/49d466ab041ef73c7b13e8ff88be991ee637364f

I'll be taking care of this


Simpler cross-platform solution

These changes to the solution remove PowerShell and makefile scripts, but will build on with either Visual Studio or xbuild in Mono, as a typical assembly project without automatic version numbering. The makefile didn't work for me and this seems like the simplest solution to maintain.

@stever It seems that most of your good points have been covered by changes we've made on the vNext branch. Can I ask you to please have a look at vNext and see whether there is anything missing from what you wanted to achieve? Here is a high-level assessment from my point of view:

"Fixing case-insensitive path ..." is covered.
"Use the default Debug and Release output paths" is not covered. I would also support using the default paths. And while this would normally be a breaking change, the other changes we've made will already break existing paths. So, now would be the time to make the change you are suggesting.
"Removing makefile and powershell scripts" is covered, at least mostly. I've just seen one leftover makefile.def in the Open-XML-SDK project folder (you'll only see that folder on vNext).
"Replaced the OpenXmlObsolete ..." is partly covered. Travis CI complained at one point, so I replaced that one string. But we could certainly be consistent and replace them all.
"Updated README" is not covered. We still have to update the README file. However, there are other updates pending, so @EricWhiteDev will probably have to do this while reflecting your changes.

I will let @EricWhiteDev chime in on how we want to move forward with this PR. One way would be for you to create a feature branch off of vNext, manually reapply the outstanding changes, and create a new PR for merging your branch into vNext (not master). Otherwise, you'd have to rebase on vNext (which already contains some of the changes on top of structural changes).

Hi @ThomasBarnekow. Thanks for taking the time to respond. I appreciate that these things are being handled along the same lines and there isn't much that is important in this pull request. I'll pick up the changes from trunk. I might contribute something more useful in future. I've got more than a passing interest in the library, but not a lot of time I suppose. Still I'm using this and also cross-platform which is really good to see. It doesn't take much work to do that. Hopefully stays that way :)

Hi @stever, you'd have to pick them up from vNext rather than master. Not sure when @EricWhiteDev will merge vNext into master, but that might take a little while. Anyhow, vNext will always have the latest and greatest functionality.
We are also looking to improve cross-platform availability. Currently, there are issues with System.IO.Compression on Mono, for example. And xUnit 2.0 doesn't work on Mono due to a bug, so we can't run our test cases at the moment. We'll have to wait a little while until this gets fixed.

Sure I'll take a look at vNext sometime. Thanks again.


Test for FieldError.Also(nil)

Adding a nil error to a FieldError should be a NOP and there was no test for it. The implementation is already correct; this just adds a test for it.

/retest


Move PIP and PIP template to codebase

Motivation
According to the discussion https://lists.apache.org/thread/4gwcy3ds2mcmdmcrso24bx55wzlz2gp8
This is the first PR to move the PIP and PIP template into codebase
This PR 100% copied from the wiki page, any improvements should happen with additional PRs which
will have all the historical records.

Please see my comment on the mailing list https://lists.apache.org/thread/0w2s87yp79sqdfdk7o8tfq90o9x20c9n.

This can be a significant process change. We should reach an explicit consensus first instead of rushing into PRs. Especially, we don't know what clear proposal process we agree on now.

@tisonkun I have replied to the mailing list to avoid confusion. This PR is not intended to change something before we have a result on the mailing list. As I said in the PR description, just to be able to reflect all subsequent modifications(historical records). Thanks for point it out, it might also confuse other people.


Create Package: Groups to Tabs

I created a new package that converts Groups to Tabs for all property groups 😀 a handy utility when migrating old websites that need a quick "tidy up".

Screenshots

Also, does upgrading any of my existing packages to v15 count as a contribution? For example Cloudflare Media Cache - 15.0.0-alpha0001

Cool, thanks @jcdcdev!


[Question] Shutdown Service not working? Maybe im doing it wrong....

I just want my NAS to shutdown when  something is triggered.
When I test the action, it just throw a "Unknown Error"  pop-up and nothing happen.
maybe im doing it wrong?
I used a targer using device and choose the "system", but it just throw a "Unknown Error" message, chooising the other 3 makes no sense (disk, services, filesystem) but I tried choose those instead and same error. Using the entities as target and nothing on the list makes no sense to use to shutdown my NAS.
running version 6.5.3-1 (Shaitan).

you have to target uptime sensor entity.


DataTemplateView may not work in some cases

For example, MenuItemTemplate from FluentAvalonia.NavigationView. The viewFunc can be triggered, but the view is not applied.
You have to use builtin FuncDataTemplate instead.
It seems that it's because of NavigationView requiring NavigationViewItem as top element in template. And it doesn't fit the restriction.
Is there a different behavior from FuncDataTemplate or something I did wrong?
// this works
FuncDataTemplate<string>(fun value scope ->
    let nvi = NavigationViewItem()
    nvi.Content <- value + "!!!"

    nvi)

// this doesn't work
DataTemplateView<_, _>.create (fun item ->
    create<NavigationViewItem> [] (fun nv -> nv.Content <- (item + "!!!"))) // my wrapper calling `init` and ViewBuilder for third party controls

DataTemplateView<_, _> can you fill in the types here ind make sure the template matches the data type?

Yhea, it is DataTemplateView<string, IView<NavigationViewItem>>.
This doesn't work either. And with a break point set I can see the template is called twice with item being "a". Which just like returning an element other than NavigationViewItem in FuncDataTemplate, the template is discarded samely.
(With source [ "a"; "b"; "c" ])


update journal-related typings for v10

this PR updates the typings for JournalEntry and adds typings for JournalEntryPage, along with their corresponding sheet applications and schemas.

resolves #1963
resolves #1964
resolves #1873
resolves #1872
resolves #1942
resolves #2152
resolves #2151

evidently i did JournalPageSheet but neglected JournalSheet. reverting this to a draft until that's remedied.

Is there anything I can do to assist with getting this unstuck?


Create a well-defined way to pass infra data to components

General
In many cases, a Lokomotive component may need information from the infrastructure layer (Terraform). Examples:

A component should only be deployed on AWS.
A component needs to know the IP address of a machine (as in https://github.com/kinvolk/lokomotive/pull/493 for example).

We should think about adding a generic mechanism for making infrastructure data available to components.
Implementation
Terraform knows everything about an infrastructure. Therefore, it probably makes sense to rely on Terraform outputs as the source of the information.
There are at least two main approaches on how to make information available to component: via lokoctl and via the k8s datastore.
Passing information via lokoctl
In this approach, lokoctl contains logic which reads Terraform outputs into memory. The components code can then use the in-memory information to interpolate values into component manifests, enable/disable components altogether etc.
If this approach is taken, it is critical to re-apply components following an infrastructure change.
Passing information via the k8s datastore
In this approach, Terraform outputs are written to the k8s datastore as k8s objects (e.g. using ConfigMap objects or custom k8s resources). Then, a component manifest can refer to a value from the relevant k8s object rather than using a hardcoded value.
IMO this approach is problematic for the following reasons:

You can't know exactly how a component is going to behave by looking at its rendered manifest.
You can't decide not to deploy a component altogether based on a value derived from the infrastructure.

@iaguis @surajssd @invidian - FYI.

Some thoughts:

This issue should also go together with reducing the amount of things the Terraform is responsible for (#181), as e.g. right now it deals with generating Helm chart values and current way of propagating the information is very complex because of that. Terraform should ideally be only responsible for talking to Cloud APIs to create the infrastructure. This means, for some things, it might make more sense to move them outside of Terraform, instead of creating them in Terraform and then passing them to the components configuration.
I am also in favor of doing that in the lokoctl over passing the information via k8s. This again, reduces the amount of responsibility for Terraform. As we discussed in #364, at least on the code level, the components should be the "property" of the cluster, and so should be the infrastructure part of the cluster. This means, the plumbing we implement should be stored in cluster-related code. The relation diagram would look like following:

For this kind of component configuration enhancements, we should decide if we want to support opting-out from these. This means, if component A is being installed because cluster is on platform B, should user have an option to disable this integration?

Using kubernetes as data store makes more sense from the perspective of controllers and operators.
Going forward when Lokomotive relies on it’s own operators and controllers, getting that information from terraform output would pose same problem we have today; How to extract data from terraform!

@surajssd I think considering controllers is slightly beyond our scope for now, as I think we will still need Terraform for infrastructure parts, at least initially, so it doesn't really matter where we run it.


feat(module:code-editor): add global configuration to support monaco require config

add global configuration codeEditor.extraConfig to support monaco require config

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
monaco required configuration, for example
const ngZorroConfig: NzConfig = {
  codeEditor: {
    assetsRoot: `https://cdn.jsdelivr.net/npm/monaco-editor@latest/min`,
    extraConfig: {
      'vs/nls': { availableLanguages: { '*': 'zh-cn' } }
    }
  }
};

Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

@hsuanxyz Can you check this PR?


Add Support for namecheap

Would be awesome if someone could implement namecheap support!
https://www.namecheap.com/support/api/intro.aspx

Any update on that ? I see that in 3.0 there is namecheap but it's not working  .

still no answer to this.

Namecheap will not be supported in the near future since their slow DNS propagation doesn't play well with ACME domain validation.


Update how VS Build Tools is installed

In the VS 2019 example Dockerfile, it creates a separate installation of VS Build Tools rather than modify the existing installation of Build Tools from the sdk base image.  I've updated it to make use of the existing installation instead.
I've also modified the way in which the bootstrapper is downloaded.  The previous way using the ADD instruction caused unnecessary bloat in the resulting image because the vs_buildtools.exe is contained in an image layer (even deleting the file in a separate layer wouldn't solve this because the layer in which it was downloaded still exists).  I've modified the pattern to download the bootstrapper with curl and delete the bootstrapper after installation, all in the same layer.  This prevents the bootstrapper exe existing within the built image.  I applied this same pattern to the VS 2017 Dockerfile.
Fixes https://github.com/MicrosoftDocs/visualstudio-docs/issues/6748

@mthalman : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


DEP Update JS dependencies

Issue https://github.com/silverstripeltd/product-issues/issues/505

Closed in favor of https://github.com/silverstripe/silverstripe-mfa/pull/440


examples: run mypy on repo example

repository example is not completely annotated. mypy config (currently in setup.cfg) does not cover the example: it should cover the whole examples/ directory.
It looks like this means some minor annotation fixes in the example (mostly to deal with roles dictionary items).

Quick question, is there a consensus (#1130, #1301..?) to use type annotations everywhere?

I ... don't know. I like them so much now that I just kind of assumed.
To be clear, I do think that

we should aim to cover most of our code with static typing
we should document this as the safest way to use the APIs: if applications check types statically that means our validation code can concentrate on validating deserialized json (instead of concentrating on validating application provided input)

I can take this one as I already added examples locally when addressing comments for #1699.


"Elementum Play" via context menu: What is the expected behavior?

Kindly confirm what the expected behavior of ELEMENTUM PLAY via the context menu is so I can determine if I'm encountering a bug or not.
I was under the impression that this contextual option could be called from any other video add-on, and it would send the item to Elementum Burst to begin scouring for content similar to the Magnetic/Magnetizer add-on. However, when used this way the only result is a pop-up a notification informing the user that th item is playing in Elementum, but nothing happens.
I will be happy to submit logs and other details if I am correct in my assumption of the intended behavior.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Version used:

Environment name and version:

Operating System and version:

Link to Kodi debug log:

elgatito, I was trying to play it from the Exodus Redux context menu, "Elementum Play" and nothing happens.
Elementum 0.0.62 GoTorrent: 148bb977 Go: go1.11.2
Kodi (17.6 Git:20171119-ced5097). Platform: Android ARM 64-bit
NVIDIA SHIELD Android TV with Android 8.0.0 API level 26, kernel: Linux ARM 64-bit version 3.10.96-tegra
Full Kodi debug log: https://pastebin.com/raw/gKry4u5j
Relevant portion of debug log: https://pastebin.com/raw/RjuFSEvd
More over, the same non-results happen if I select Elementum Play from the context menu in the Elementum add-on. Here is the full kodi log for that https://pastebin.com/raw/UynwMmQp
Perhaps there is something I haven't set up correctly.

Does the content that is accessed via "Elementum Play" in the context menu need to be added to the library first? That's the only way I can think of that it will have a TMDB ID assigned to it, and it does work on Library items.

I don't see any information from context plugin in the log. You should enable debug logging  in Kodi to see all the information.

Current implementation can play videos from Kodi library and Elementum items.
Searching for custom queries was disabled long ago.

I have made a newer version of context.elementum plugin which now uses direct search queries for non-Kodi items.
You will need next version of Elementum to handle them, so "Elementum Play" will search whatever you click it.

Context menu > Elementum Play > Notification pop-up says, "Playing with Elementum: {Episode name here}" followed by a notification pop-up that says, "Elementum not found"
Elementum Context Helper 0.0,2
Elementum  0.0.62
Relevant portion of debug log: https://pastebin.com/raw/65X2kBju

Please, try with 0.0.63, it should now search, whatever is gotten from Kodi.

@metaltermite  Any feedback?

@elgatito Sorry for the lack of feedback. I can confirm it works now. TPB times out, but otherwise it works perfectly.

By "Times out" you mean search with Burst is not working for TPB?


JAV-234 added unit tests for filters

Coverage increased (+5.3%) to 66.311% when pulling bbec6786856f4034bf9ad3e605ca0791b43b44dc on eric-lee-ltk:JAV-234_support_zuul into 223862613d6e7d38d000748b94289757b78a4d7f on WillemJiang:master.

Coverage increased (+5.4%) to 66.362% when pulling 17c2ea58d400871861f6b26e16ca5f9699350653 on eric-lee-ltk:JAV-234_support_zuul into 223862613d6e7d38d000748b94289757b78a4d7f on WillemJiang:master.

Coverage increased (+5.5%) to 66.464% when pulling f4a69e300733c82a70b0884be5d9477d17a2545c on eric-lee-ltk:JAV-234_support_zuul into 223862613d6e7d38d000748b94289757b78a4d7f on WillemJiang:master.


add live capturedpacket info to UI

add captured packet info for live traffic as part of destination Node diagram.
sample screenshot:

pod to pod:

empty source to pod:

Codecov Report

Merging #2182 (938e6e6) into main (771477a) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2182      +/-   ##
==========================================
+ Coverage   41.33%   41.35%   +0.01%
==========================================
  Files         132      132
  Lines       16539    16539
==========================================
+ Hits         6837     6839       +2
+ Misses       9115     9114       -1
+ Partials      587      586       -1

Flag
Coverage Δ

unit-tests
41.35% <ø> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apiserver/storage/ram/store.go
78.94% <0.00%> (+1.50%)
:arrow_up:

@mengdie-song I tried to align the capturedpacket to the bottom but the result looks worse(not sure why), so I leave it as default setting.

@mengdie-song after double check UI, I think the source and destination cluster is not in one line is not introduced by live packet info. you can see below screenshot for normal one:

looks like the dot language graph will make sure the last nodes to align vertically and centrally, if the label strings in two nodes have different lines, then you will see such situation. and I tried to remove two lines then you can get below screenshot.

so I  think there is a behavior of dot language graph, can't be controlled by some custom setting.

/skip-all


Suport node and IP discovery without kvstore

Now that the identity allocation is supported via CRD, the remaining blockers to enable kvstore free operation is node and ipcache discovery.
This PR fixes all remaining issues to run Cilium without a kvstore by adding support for both node and ipcache discovery via existing Kubernetes custom resources.

This change is

Coverage decreased (-0.08%) to 44.175% when pulling c1c79cce746dbd87160797db0723aa455dbaf499 on pr/tgraf/node-crd into 620068e100b0b046d45d11bdf594426065701ebe on master.

test-me-please

/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/k8s-1.10-gopath/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:420
unable to apply https://raw.githubusercontent.com/cilium/star-wars-demo/v1.0/01-deathstar.yaml:
Expected command: kubectl apply -f  https://raw.githubusercontent.com/cilium/star-wars-demo/v1.0/01-deathstar.yaml
To succeed, but it failed:
Exitcode: 1
Stdout:

Stderr:

Looks like it hit #8634

test-me-please

@tgraf https://github.com/cilium/cilium/pull/8627#issuecomment-513896175 could have occurred due to connectivity issues trying to get the resource from GitHub, as the call to kubectl apply in the demos.go test has a timeout of 30 seconds to apply to resource, which is a reasonable amount of time. I suspect this may be due to GitHub having disruption of service earlier today.

test-me-please

CI: green build.
One local change not pushed yet:

Missing encryption key derival based on CiliumEndpoint CRD as pointed out by @jrfastab via Slack. The current code always uses the local node key.

Rebased to include #8573 and to push change referred to by comment https://github.com/cilium/cilium/pull/8627#issuecomment-513972844

test-me-please

CI: green build
Pushing to address Ray's comment

test-me-please


not working on react native 0.18

the action button overlay view catch touch event even on inactive, so other view below can not touchable

Thanks for the issue @iwater !
It's fixed in v1.1.1. Just update the package by calling: npm install react-native-action-button@latest --save.

Are you sure it's fixed ?
I have the same problem with react native 0.28 and a Mapbox below the FAB. It's impossible to drag the map.

Are you using the latest version of the package? If so, can you try with v1.1.7 or below? Maybe the bug occured with the latest PRs

It's perfectly working on 1.1.7 but not on the latest version.
I'll stay with the 1.1.7 thus.

thanks for checking

On 05 Jul 2016, at 19:52, Nicolas Cognaux<EMAIL_ADDRESS>wrote:
It's perfectly working on 1.1.7 but not on the latest version.
I'll stay with the 1.1.7 thus.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.


Show Description and Field name as tooltip (when hoovering over the label)

When hoovering over the field label, the label name is shown as tooltip. I expect the Description and Field name to be shown in the tooltip (as also is shown for other fields). Especially the showing field name is handy, when you do not know the fieldname and want to use the field in a work item query.

Thanks for the feedback. I will put this issue on our internal tracking board so the product owner can prioritize it.
You are always welcome to create a pull request your self to improve the extension.


Created close-old-issue.yml

Fixes #49

@Asymtode712  Hi , make sure that the PR does not include the Contributing.md of some other git repository .
Please modify it correctly and to the point .

@dhruvpatidar359 I have done the changes as requested by you, please review my PR and merge it with relevent gssoc labels if it is good to go

@dhruvpatidar359 I have done the changes as requested by you, please review my PR and merge it with relevent gssoc labels if it is good to go


Update class names

This PR:

Updates class names to be in line with other crypto libs
Re-adds the sha2-256 and sha2-512 modules so we don't break others' projects

Forgot. Native does not like same names with different cases. Will have to move new classes under a new package name.


Update sbt-mdoc to 2.3.0

Updates org.scalameta:sbt-mdoc from 2.2.24 to 2.3.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "sbt-mdoc" } ]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1

This PR will conflict with https://github.com/typelevel/cats-time/pull/339. Please consider reviewing that one instead. Thank you! :)

Can we close this one?

Yes, you get mdoc through sbt-typelevel now.


fixing old variables in documentation

Fixing old CV_ constants for imread and imwrite properties.

I'd suggest to move modes documentation to the corresponding enumeration (name it first, something like ReadModes or ImreadModes). And add reference to this enumeration to the imread and imreadmulti methods documentation (implicit cv::ReadModes or explicit @ref cv::ReadModes).
It will look like kmeans documentation with link to the KmeansFlags.
Same thing with imwrite flags.

@mshabunin when I got some time I will address these issues and change them to your suggestions!

@mshabunin applied fixes! Some remarks in code itself!

Fixes applied!

Thank you!
:+1:

Great!


Make the prevent_item_use power type work on block items

This PR makes the prevent_item_use power type work on preventing 'usage' and 'placement' of block items. It also adds a new include_block_items boolean field that has a default value of false to keep the initial behavior of the power type

Should we follow the technical distinction of "block items" being "items", or would it be preferrable to create a new prevent_block_placement power type instead, in order to keep in line with what a regular MC user considers a "block"?

I'd say the latter would be better, just to be safe

This has now been superseded by https://github.com/apace100/apoli/pull/54, which adds a new prevent_block_place power type


Support policy matching against kube-apiserver

See commit msgs.
This PR implements support for automated policy matching against the
kube-apiserver. It does so by detecting where the kube-apiserver is running,
whether it's inside the cluster or not.
TODO:

[x] Implement K8s delete event handling to cleanup ipcache & IdentityMetadata map
[x] Implement user-facing policy constructs like ToEntities
[x] Support kube-apiserver running outside of the cluster (CIDR)
[ ] Merge and rebase:

[x] https://github.com/cilium/cilium/pull/17778
[x] https://github.com/cilium/cilium/pull/17724
[ ] https://github.com/cilium/cilium/pull/17668

[ ] File issue to create an end-to-end test inside k8sT/Policies.go

Fixes: https://github.com/cilium/cilium/issues/14724

/test

/test

Superseded by #17823, which is now merged. Closing. @christarazi I've left some comments open here and will be happy to discuss with you about any remaining items from here or the other PR when you're back.


Fix package installation on Windows

Fixes "ValueError: path './' cannot end with '/'" pip install error on Windows

Thank you!


[TEST] Support v2 volume in daily regression(pytest)

What's the test to develop? Please describe
Current pytest test cases are migrating to our new test framework which implemented with robot framework and the new test framework support create v2 volume and testing.
To maintain consistency during this transition, adding v2 volume support to pytest, allowing exist test cases can test v2 volume as well until the migration to the new framework is complete.
Describe the tasks for the test
N/A
Additional context
N/A

test_basic.py
There are 29 test cases currently not worked for v2 volume, most of the reasons are

feature not supported v2 volume

volume expansion
backing image
delete snapshot after volume head
snapshot prune

Test cases/functions need to refine

crash_replica_process
find_replica_for_backup

Test case not support v2 volume
reason

test_volume_iscsi_basic
not support iscsi

test_backup_status_for_unavailable_replicas
need to refine function find_replica_for_backup

test_expansion_basic
not suppoer volume expansion

test_expansion_with_size_round_up
not suppoer volume expansion

test_restore_inc_with_offline_expansion
not suppoer volume expansion

test_expansion_canceling
not suppoer volume expansion

test_expansion_with_scheduling_failure
not suppoer volume expansion

test_expand_pvc_with_size_round_up
not suppoer volume expansion

test_volume_toomanysnapshots_condition
volume.snapshotPurge not work on v2 volume

test_snapshot_prune_and_coalesce_simultaneously
can not delete snapshot after v2 volume head

test_snapshot_prune
can not delete snapshot after v2 volume head

test_snapshot
can not delete snapshot after v2 volume head

test_space_usage_for_rebuilding_only_volume
test method not worked on v2 volume

test_space_usage_for_rebuilding_only_volume_worst_scenario
test method not worked on v2 volume

test_backup_failed_enable_auto_cleanup
crash_replica_process not work on v2 volume

test_backup_failed_disable_auto_cleanup
crash_replica_process not work on v2 volume

test_dr_volume_activated_with_failed_replica
crash_replica_process not work on v2 volume

test_running_volume_with_scheduling_failure
crash_replica_process not work on v2 volume

test_filesystem_trim
unmapMarkSnapChainRemoved can not enable in v2 volume

test_volume_backup_and_restore_with_lz4_compression_method
not support backingimage yet

test_volume_backup_and_restore_with_gzip_compression_method
not support backingimage yet

test_volume_backup_and_restore_with_none_compression_method
not support backingimage yet

test_cleanup_system_generated_snapshots
need to refine test case

test_allow_volume_creation_with_degraded_availability_dr
need to refine test case

test_allow_volume_creation_with_degraded_availability_restore
need to refine test case

test_restore_inc
need to refine test case

test_volume_metafile_empty
need to refine test case

2 test cases in test_recurring_job.py do not support v2 volumes.

Test case name
reason

test_recurring_job_snapshot_cleanup
not support volume expansion

test_recurring_job_snapshot_delete_retain_0
can not delete snapshot after v2 volume head

Current work on test_system_backup_restore.py

7 test cases in test_scheduling.py do not support v2 volume.
test cases need to refine due to in current implemention, extra disks for test is gererated in filesystem type, which means those disks not support v2 volume, it need more time to reine and test.

Test case name
reason

test_soft_anti_affinity_scheduling_volume_enable
can not set replicaSoftAntiAffinity for v2 volume

test_soft_anti_affinity_scheduling_volume_disable
can not set replicaSoftAntiAffinity for v2 volume

test_replica_auto_balance_disabled_volume_spec_enabled
can not set replicaAutoBalance for v2 volume

test_replica_auto_balance_disk_in_pressure
need to refine test case

test_replica_schedule_to_disk_with_most_usable_storage
need to refine test case

test_global_disk_soft_anti_affinity
need to refine test case

test_volume_disk_soft_anti_affinity
need to refine test case

currenly working on test_csi.py for v2 volume test

6 test cases in test_csi_snapshotter.py currently do not support v2 volume.

Test case name
reason

test_csi_snapshot_snap_create_volume_from_snapshot
v2 volume not  support volume clone

test_csi_snapshot_snap_delete_csi_snapshot_snapshot_not_exist
can not delete snapshot after v2 volume head

test_csi_volumesnapshot_backing_image_basic
v2 volume currently not support backing image

test_csi_volumesnapshot_restore_pre_provision_backing_image
v2 volume currently not support backing image

test_csi_volumesnapshot_restore_on_demand_backing_image
v2 volume currently not support backing image

test_csi_volumesnapshot_backing_image_with_selectors
v2 volume currently not support backing image

@chriscchien Regarding https://github.com/longhorn/longhorn/issues/9760#issuecomment-2496495943, if crash_replica_processes doesn't work on v2 volumes, would delete_replica_processes work instead? Have you encountered a test case that involves calling delete_replica_processes?

I did not tried delete_replica_processes on v2 volume yet, if it worked on v2 volume, I would prefer to perform this after https://github.com/longhorn/longhorn-tests/pull/2170 completed first to avoid massive code change and validation, additionally, I would prefer to move those test cases directly into the e2e cases.

@shuo-wu @PhanLe1010
Any suggestions?

2 test cases in test_migration.py currently do not support v2 volume.

Test case name
reason

test_migration_with_failed_replica
delete /var/lib/longhorn/replicas not make v2 volume replica fail

test_migration_with_restore_volume
need to wait https://github.com/longhorn/longhorn/issues/9987 resloved first then validate this test case


pma-voice  could not be connect again, and or disconect

Issue
Voice chat doesn't work,
or get disconnected and not reconnect automatically
To Reproduce
Install Qbus Framework
Install pma-voice
enable onesync-infinity
Expected behavior
I wish voice chat works better and when disconnected, I can reconnect myself, I tried to find reconnect config but couldn't find it
Server Info:

Server Version: 4460
Client Version: I do not know
Client Build: b2189

Additional contexte
[https://cdn.discordapp.com/attachments/866466102762536973/888795162082443304/unknown.png]

That message is a debug message, either way, it is just showing you that you connected to the mumble server, the 'is this a reconnect' is exactly as it says if it's a reconnect (aka they were previously connected) it will be true.

Thank you for your reply, but can you guide me on how the client often loses voice in the game, I would appreciate it if you could guide me.

Can you provide your settings

setr voice_useNativeAudio 1
setr voice_useSendingRangeOnly 1
setr voice_zoneRadius 256
setr voice_enableUi 1
setr voice_enableProximityCycle 1
setr voice_enableRadios 1
setr voice_enablePhones 1
setr voice_enableRadioSumix 1
setr voice_defaultCycle "X"
setr voice_defaultRadio "CAPS LOCK"
setr voice_defaultVolume "3.0"
setting curent my server


Use custom resolver for query and eval with nested frames.

Verify preflighting of nested expressions using AST visitation.
Remove logic for splitting queries by string.  Now the evaluation is handled by a nested column resolver, and the mixed-mode expressions are preflighted by examining the parsed abstract syntax tree for the query expression.
Resolves https://github.com/lincc-frameworks/nested-pandas/issues/59.

Change Description

[X] My PR includes a link to the issue that I am addressing

Solution Description

Code Quality

[X] I have read the Contribution Guide
[X] My code follows the code style of this project
[X] My code builds (or compiles) cleanly without any errors or warnings
[X] My code contains relevant comments and necessary documentation

Project-Specific Pull Request Checklists

Bug Fix Checklist

[X] My fix includes a new test that breaks as a result of the bug (if possible)
[ ] My change includes a breaking change

[ ] My change includes backwards compatibility and deprecation warnings (if possible)

Thank you!
I'd ask for more testing and not-implemented error-handling. For example, I'm not sure that assignment with eval is supported: .eval("nested.c = nested.a + nested.b") or .eval("nested.b = x + nested.a").
It looks like it may also close #144 and #146? If yes, could you please add tests for covering those issues?

Yes, this PR does resolve #146, thanks for the tip!  #144 is not resolved by this PR, but perhaps this same approach could be extended to cover it in a separate PR.
Good catch on the assignment problem.  The existing ability for eval() to insert base columns still works, but you're right, it can't insert into the nest yet.  I'll add those tests and see if adding nested columns can be done within the scope of this PR.  If not, I'll at least make a clearer error.

Thank you!
I'd ask for more testing and not-implemented error-handling. For example, I'm not sure that assignment with eval is supported: .eval("nested.c = nested.a + nested.b") or .eval("nested.b = x + nested.a").
It looks like it may also close #144 and #146? If yes, could you please add tests for covering those issues?

Yes, this PR does resolve #146, thanks for the tip! #144 is not resolved by this PR, but perhaps this same approach could be extended to cover it in a separate PR.
Good catch on the assignment problem. The existing ability for eval() to insert base columns still works, but you're right, it can't insert into the nest yet. I'll add those tests and see if adding nested columns can be done within the scope of this PR. If not, I'll at least make a clearer error.

The changes I pushed yesterday do permit assignment of nested columns, and even the creation of new nests, from within eval()!  Added tests of this as well.

This is great! I think the eval interface here is a huge addition to nested-pandas, to the level that I would love to see it in our documentation. I wouldn't ask it for this PR, but perhaps in a future PR we could add a section to the data manipulation tutorial showcasing some of the uses of eval?

Great idea!  I'll add a task for that.


Feat/sdk readonly client

PR-Codex overview
This PR adds support for ReadClient in the database module and provides additional documentation and examples for using db3.js.
Detailed summary

Added support for ReadClient in the database module
Updated documentation with links to relevant examples and resources
Added a quick start guide with code examples and an image
Updated README with information on connecting to the db3 cloud sandbox

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Codecov Report

Merging #536 (7bf6cce) into main (1c8bce3) will not change coverage.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #536   +/-   ##
=======================================
  Coverage   55.39%   55.39%
=======================================
  Files          72       72
  Lines       13994    13994
  Branches       61       61
=======================================
  Hits         7752     7752
  Misses       6242     6242

Flag
Coverage Δ

rust
55.39% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

sdk/src/store/database_v2.ts
81.42% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


howto example doesn't run on macOS

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
     Running `/Users/jrmuizel/src/glow/target/debug/howto`
thread 'main' panicked at 'ERROR: 0:1: '' :  version '130' is not supported
ERROR: 0:2: '' :  #version required and missing.
', examples/howto/src/main.rs:86:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Thanks! We could probably default to OpenGL 3.2 or higher on macOS and bump the version in the shader.

@grovesNL pull/238 tested on MacBook Pro M1 Max with macOS Ventura 13.0

Fixed by #238


Break project into three modules

Remove sourceSet hackery, replace with api, core and processor module.

addressed in #10


Migrate documentation from README.md to Wiki

Thank you very much for setting up project wiki!
I'd only ask to redirect this PR to v2.0 branch, as the documentation change will be a part of the new major release.

Thank you very much for setting up project wiki!
I'd only ask to redirect this PR to v2.0 branch, as the documentation change will be a part of the new major release.

done! thanks a lot for the review!

done! thanks a lot for the review!


Issue of broken links to translated docs #2

This is a Bug Report

Problem:
There are lots of translated docs contains broken links of redirects to the translated docs in content/ko/docs directory.
Proposed Solution:
Fix these broken links to the translated docs.
Page to Update:
https://kubernetes.io/...

/language ko

/assign


feat: draft of new feature flag panel design

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
Added a new component called "Actionables" which groups all actions represented as icons.
Modified PanelSearch component to receive "viewMode" and "toggleViewMode", so it shows a Switch on the left of the filters ta toggles the viewMode.
That's just a draft of what i understood about @kyle-ssg and @novakzaballa ideas. There's still a couple problems:

I'm not used to the codebase tools, so i'm probably using something that could be replaced by a already existing tool;
I couldn't make it initiate the view State from localStorage, and honestly, i don't really know why i couldn't grab the value calling the localStorage from componentDidMount. So it saves the state, but can't retrieve it.
The styling is more a POC than a real one.

How did you test this code?
I tested through my development environment at the features page.
Video for a quick peek:
https://github.com/Flagsmith/flagsmith/assets/77826309/dc3a8a05-fee2-4277-9a4d-1f248163ed9d
Related to: #2942 and #2981

@MatheusLasserre please make sure that you are following the contributing guidelines. PR titles need to follow the Conventional Commit structure, I'm also not sure what 'panel actions state' really means so please make sure the title is descriptive of the change in the PR. Also, this change seems to have broken the E2E testing but I see you've mentioned that there are outstanding problems in the PR. I've marked the PR as draft while it's still in progress.

@MatheusLasserre please make sure that you are following the contributing guidelines. PR titles need to follow the Conventional Commit structure, I'm also not sure what 'panel actions state' really means so please make sure the title is descriptive of the change in the PR. Also, this change seems to have broken the E2E testing but I see you've mentioned that there are outstanding problems in the PR. I've marked the PR as draft while it's still in progress.

Sorry. I've made some changes to make sure it's following the guidelines.
The broken E2E, it's probably with the problem of the tools I've mentioned. But this PR aims more to give an idea than to be merged, unless you really like the ideia. In that case, i would change it.

My main concern here is the mouse movement required to hit these buttons is very fiddly...I like the idea overall but maybe it should be a clickable element with a popup rathen than something that appears onHover?

Maybe i could make it sizes differently based on the compact/normal view?
I've made it onHover because @novakzaballa mentioned that he would like to not have the usual clickable context menu.
And since the idea of the  I've created was to store quick actions, like the created at, clipboard, etc, i think the onHover makes sense.
The scenario i imagine to think of this is the following:
A user wants to copy the name and check the creation date of some feature flags.

OnHover:

Hover the card, clicks copy, hover created at, then next.

Clickables:

Clicks menu, clicks copy, hover created at, clicks outside, then next.
I feel like the onHover approach makes more sense is that scenario.
Changing it based on the view would change the following:

The actual model would stay the same for the normal view, since it adapts itself for the height of the upper row, which we always know the height.

The actual model would change when in compact view to have the icons the same size as the current "feature flag history" button, while it would maybe reduce the width of the flags.

Right now the icons are with the same size as the default tooltip.
If that new idea makes sense, i can make some changes and post a new video here to show it.

Thanks for the work here @MatheusLasserre and all the conversations but, as per the conversation on this PR, we're going to take a step back and look at this with our design team. AS such, I'll go ahead and close this PR for now.


research replacing file browser with a std lib

https://github.com/Kloudless/file-explorer

i could have sworn we had an issue for this already but i can't find it.

looks like kloudless support for local filesystems is an upsell, so we are looking at https://github.com/Studio-42/elFinder instead (but using a Java server instead of PHP).

This seems like a good option if we can skin / restyle it.


Bringing OsStr and CStr up to par with str

Redirected from https://github.com/rust-lang/rust/issues/22741
Using starts_with() as an example:
Right now one can do this on OsStr by:

requiring the OsStr to be utf-8 (and converting it to str/String)
Or implimenting a unix version using as_bytes(), and a windows version using encode_wide()

Unfortunately, the lack of a common method for iteration over elements of the OsStr means that any out-of-std implimentation of these will be un-happily platform specific.

It's not clear to me why we can't expose the underlying representation with some sort of .as_bytes(). Is it just because we assume people are gonna assume that on Windows that means it's the active codepage and not WTF-8?

#1876 discusses some ideas for how slicing could work for CStr.

See also:

https://github.com/rust-lang/rust/pull/26499, an unmerged implementation of starts_with and ends_with and discussion of generalizing the Pattern API to OsStr.
https://github.com/rust-lang/rfcs/pull/1309, a promising RFC involving the OsStr API.
https://github.com/rust-lang/rust/issues/40300, discussion of prefix comparison for OsStr.

For everyone still waiting on this issue, I created OsStr Bytes, which should make OsStr and OsString much easier to use.

@dylni I realize you're intentionally invoking UB in that crate, but it's still UB and I therefore wouldn't recommend that approach: https://github.com/dylni/os_str_bytes/blob/ff8a9ed5e7d50b9ff63ea20bfd460a7f481340c1/src/windows.rs#L16-L28
bstr does as much as is possible with as little work as possible without breaking abstraction boundaries or invoking UB: https://docs.rs/bstr/0.2.8/bstr/#file-paths-and-os-strings

@BurntSushi I completely agree and was hoping to hear some opinions on this, which is why I put it on the front page of the documentation. My plan is to come up with something better before a 1.0 release, but I haven't yet decided what the best option would be. However, I don't agree with the approach of not being able to handle some valid arguments on Windows, which is why I created the crate.
I may just end up copying next_code_point() from the standard library, but I haven't decided yet. The problem with this is that bytes could be mangled if the standard library implementation changes, which is why I've avoided it so far.

@BurntSushi That method is no longer called.

About starts_with, how about
impl OsStr {
   fn starts_with(&self, prefix: &OsStr) -> bool
}

?
This way I won't have to handle Option like osstr.to_str().map(|x| x.starts_with("prefix")).unwrap_or(false);, but I would be able to do osstr.starts_with(String::from("prefix").into()).


Patching or  installing GmsCore in priv-app

Note: On Android 7 (or later) an additional patch is needed to make location work, or alternatively, you can install GmsCore.apk in the /system/priv-app folder.

I'm running LineageOS 15. I managed to follow your installation guide from the beginning to the end, except for the very last part (quoted above).
Are there any detailed instruction for this anywhere? I'm not really sure how to apply this patch or how to move GmsCore to the right location.
Thanks for your work, it's amazing.

Indeed, the whole documentation could need a revamp, but basically:

Remount system partition as rw, see https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro for instance.
Run adb push GmsCore.apk /system/priv-app.
Remount system as ro.
Reboot.

They are other ways (I know some apps allow doing it from the system —with root right ofc). And if you can wait for official LineageOS 15 builds, then you would just need to install the one from lineage.microg.org.

Run adb push GmsCore.apk /system/priv-app.

To make everything work correctly, you'll want to push the apk to /system/priv-app/GmsCore/GmsCore.apk and then extract the lib/ folder from the apk to /system/priv-app/GmsCore/lib - otherwise the bundled libraries will not be found by the app and the maps library will crash apps.

@ArchangeGabriel Note that priv-apps need a special XML permissions manifest from Android Oreo onwards. You will need to push the appropiate for GmsCore and FakeStore to /etc/permissions too.

otherwise the bundled libraries will not be found by the app and the maps library will crash apps.

This is not true since Maps v2 API doesn't need bundled libraries. You'll need to push Maps v1 API jar library if you want to support those, though.

@Roboe: You misunderstood Shadow53, Maps v2 API need the library libvtm-jni.so (it is inside GmsCore.apk, you can see by opening it with a zip decompression utility).
When GmsCore is installed as normal app the library is installed automatically from Android but if you install it as system app you need to do it manually.
But there is a note about this, from about Marshmallow and up Android can use automatically libraries inside apk files without decompressing them (since GmsCore has the proper flag) but this feature isn't granted to be present in all ROMs so it is better to extract the library just to be safe.
These things apply to all system apps that contain binary libraries.

Thanks for the clarification. I've been flashing my own ZIP of microG apps since Lollipop and have not had any issues.
So, for the OP issue: it's not needed for Android Oreo, but should be done on pre-Marshmallow releases.

This feature if I'm not wrong was introduced by Google but wasn't in AOSP.
Then CyanogenMod team got it implemented but I'm unsure if all Marshmallow ROMs have it.
Also for this feature to be working the app must have in the manifest android:extractNativeLibs="false" and must be zip-aligned (GmsCore comply with this but other apps maybe be not).


React to new ObjectMethodExecutor in Common

This is for once https://github.com/aspnet/Common/pull/217 is merged and we get updated shared-source packages.

Merged a little while back.


Key Binding for HTML Elements

Hi there,
Rob asked me to post this issue -- it'd be nice if there was a way to natively bind key pressed events to HTML elements in the Aurelia binding framework.  For example, if enter is pressed on an input text box, Aurelia delegates to a function in the ViewModel to execute some work.
He also mentioned the current workaround is to create an Attached Behavior, exposing the event that can be delegated to a function in the ViewModel.  I wracked my brain for a little bit trying to figure it out, but came up blank.  Would you happen to have a snippet I can work off of?
I'm guessing the implementation on the HTML side may look something like this with the attached behavior approach?
<input type="text" enter-key-pressed.bind="enterKeyPressed()" />

Thanks!
Eric

This would be really cool although potentially hard to get right.  Would need to nail down the scope of what Aurelia would handle vs things you might use an outside framework like Mousetrap for.
Considerations:

single keys (enter, a, b, c)
modifier keys (ctrl+k, command+shift+j)
key sequences like in gmail, VS, etc
platform support, test-ability, quirks
binding multiple keys or key-sequences to the same model action
keydown/keyup/keypress
data entry elements only?

Not sure if we should have it OOTB. But it might be a good 3rd party plugin. Said plugin would leverage the event manager potentially to add custom events in combination with extending the binding grammar.

I'm closing this for now. I think it would be a great idea for a plugin though.

I see this is closed, but some native support would be nice.  Currently, if its an input field I want to enhance, I can just add keypress.delegate="keyPressed($event)" and have the VM handle it nicely.  Useful if you want to have the enter key act the same as tab in a form.
In another case, I am viewing record detail in an Aurelia Dialog.  Have previous and next buttons.  The same keypress.delegate="keyPressed($event)" doesn't work on <ai-dialog> or similar elements.  If it did, I think this issue would have been solved without Mousetrap or anything else.  For this relatively simple case I has to use a jQuery fallback, which seems to happen a bit too often.
In the Vm for my dialog:
attached() {
    this.$document.on('keydown', (e) => {
        console.log("keydown", e);
        this.keyHandler(e);
    });
}

detached() {
    this.$document.off('keydown');
}

keyHandler(e) {
    switch (e.which) {
        case 27: // esc
            this.header.controller.ok();
            break;
        case 37: // left
            this.previous();
            break;
        case 38: // up
            this.previous();
            break;
        case 39: // right
            this.next();
            break;
        case 40: // down
            this.next();
            break;
         default:
            return; // exit this handler for other keys
    }
    e.preventDefault(); // prevent the default action (scroll / move caret)
}


Teste para ganhar novos Achievements

Discussed in https://github.com/CaioCunha10/TrollScriptWhatsApp-/discussions/2

Originally posted by CaioCunha10 June 13, 2023
Got it !

Achievements Galaxy Brain recebidos.


Suggestion: automatically detect idProperty field if not provided

Would there be any disadvantage to having the attribute table widget automatically determine which ID field to use (if it's not provided) by looking for esriFieldTypeOID? It looks like the zoom to feature doesn't work correctly if no idProperty is provided.

Thanks. This is a good suggestion and will add this capability.

This has been added in commit 1d2568d

Awesome, Thanks!


Implement --head AKA -I

Addresses #42; thank you @chr4!

Wow, that was quick! Awesome :) Looking forward to the merge.

Can't make this a success without feedback from people like you @chr4; thank you! :-)
If you're able to build this from source then you can do so after it's merged, otherwise I'll likely bundle up a few more features before the next release.  Happy to do a special build for you too.  Let me know.
Cheers,
David

Thanks! I'm building from source, so once this is merged, I'll give it a shot.

@chr4 Sorry for the bad news but actually my implementation here wasn't a good one.  I'm going to retract this PR and work on a new one.  I'll reopen #42 in the meanwhile.  :-)  My apologies.


Child Trigger Deployment Error

I'm trying to use the Declarative Lookup Rollup Summaries for the first time, and when I try to deploy the Child Triggers that it requires, I'm getting this error:

Is this an error on my end?

Venturing a guess I'd say you don't have any records of that type in your
system. Or can't access them with that user.
On Wed, Mar 2, 2016, 1:44 PM acarlesimo<EMAIL_ADDRESS>wrote:

I'm trying to use the Declarative Lookup Rollup Summaries for the first
time, and when I try to deploy the Child Triggers that it requires, I'm
getting this error:
[image: image]
https://cloud.githubusercontent.com/assets/17601973/13474797/9f91702c-e08d-11e5-970d-7946fe6b1573.png
Is this an error on my end?
—
Reply to this email directly or view it on GitHub
https://github.com/afawcett/declarative-lookup-rollup-summaries/issues/310
.

Thanks @aheber I created a record with that type and it's giving me the same errror.  And I'm a system admin so I don't believe it's a permissions issue.  Any other thoughts?

I suspect its a robustness issue in the existing trigger on this object, you may have to contact that developer or use the custom test code feature of DRLS. See here for more information, https://github.com/afawcett/declarative-lookup-rollup-summaries/wiki/Challenges-with-Code-Coverage

Hopefully this helped explain the background to this issue and some next steps.


Use pydpf-actions/build_doc to generate doc (adds PDF doc generation)

This PR is an extract of #234 to isolate the new doc generation with PDF documentation.

@Revathyvenugopal162 as you might see in the artifacts once the pipelines are done, the pdf has some issues especially at the end of the file.


#51 Add reset access token functionality

Coverage increased (+0.3%) to 98.578% when pulling e7f020ff6fcc32ce8512f4f55ff7c31fdc8f2ddf on feature/51/token-reset into 5a2a9b9561827ce6625545faa4f92a157f0d7319 on master.


Namespaced ES2015 classes mapping to existing nexmo object (fixed rebase)

Replaces #54
This introduces a simple set of ES2015 classes that use the existing nexmo object for functionality.
Main changes are:

Package name updated to nexmo
Version is 1.0.0-beta-x (where x is being updated as bugs are found)
To use you now create an instance of a Nexmo object and access functionality off of namespaced properties:

nexmo.sms
nexmo.voice
nexmo.number
nexmo.numberInsight
nexmo.account
nexmo.verify
nexmo.app

Some API names have been simplified e.g. nexmo.numberInsightBasic -> nexmo.numberInsight.get({level:'basic'})
The package uses ES2015 and Babel for transpilation

Tests have been written to make sure that all functionality is still exposed and that the APIs of v0.x are mapped to v1.0. See the test files for details of the mapping.
Also see the test files for details of how the functionality has been grouped into namespaces. It would be great to get some feedback on this last point.

If this is a major version bump,  why still support the older easy Nexmo
API? Sounds like a good moment to deprecate that API.
On Mon, 16 May 2016, 12:02 Phil Leggetter<EMAIL_ADDRESS>wrote:

Replaces #54 https://github.com/Nexmo/nexmo-node/pull/54
This introduces a simple set of ES2015 classes that use the existing nexmo
object for functionality.
Main changes are:

Package name updated to nexmo
Version is 1.0.0-beta-x (where x is being updated as bugs are found)
To use you now create an instance of a Nexmo object and access
functionality off of namespaced properties:

nexmo.sms
nexmo.voice
nexmo.number
nexmo.numberInsight
nexmo.account
nexmo.verify
nexmo.app

Some API names have been simplified e.g. nexmo.numberInsightBasic ->
nexmo.numberInsight.get({level:'basic'})
The package uses ES2015 and Babel for transpilation

Tests have been written to make sure that all functionality is still
exposed and that the APIs of v0.x are mapped to v1.0. See the test files
for details of the mapping.
Also see the test files for details of how the functionality has been
grouped into namespaces. It would be great to get some feedback on this
last point.
You can view, comment on, or merge this pull request online at:
https://github.com/Nexmo/nexmo-node/pull/55
Commit Summary

WiP - Nexmo instance and namespaced functionality
Run tests against files to be published
Examples of usage for pre v1 and v1 beta
Merge branch 'master' of github.com:Nexmo/nexmo-node into namespaces
Voice class to proxy to v1 nexmo object
Move common test functionality into stub
new App class calls to underlying nexmo object
new Account class calling nexmo object
new Number class calling the underlying nexmo object
new Verify class calling underlying nexmo object
NumberInsight class.
Reply to this email directly or view it on GitHub
https://github.com/Nexmo/nexmo-node/pull/55

--
Cristiano Betta
+44(0)7518397784

If this is a major version bump,  why still support the older easy Nexmo
API? Sounds like a good moment to deprecate that API.

If folks want to use the old API they would need to:
var nexmo = require('nexmo/lib/index');

to get hold of the older reference.
So we have kind of deprecated the older API since we're saying do:
var Nexmo = require('nexmo');

var nexmo = new Nexmo({key: KEY, secret: SECRET});
// use namespaced objects to interact with the Nexmo platform

Maybe I'm missing something. What would you suggest, @cbetta ?

I say if people want the old API they do require easynexmo. Why keep the
option of the old stuff? Simplify the code base while you can.
On Mon, 16 May 2016, 12:10 Phil Leggetter<EMAIL_ADDRESS>wrote:

If this is a major version bump, why still support the older easy Nexmo
API? Sounds like a good moment to deprecate that API.
If folks want to use the old API they would need to:
var nexmo = require('nexmo/lib/index');
to get hold of the older reference.
So we have kind of deprecated the older API since we're saying do:
var Nexmo = require('nexmo');
var nexmo = new Nexmo({key: KEY, secret: SECRET});// use namespaced objects to interact with the Nexmo platform
Maybe I'm missing something. What would you suggest, @cbetta
https://github.com/cbetta ?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Nexmo/nexmo-node/pull/55#issuecomment-219401864

--
Cristiano Betta
+44(0)7518397784

I say if people want the old API they do require easynexmo. Why keep the
option of the old stuff? Simplify the code base while you can.

The point of approaching things this way (still using the old easynexmo) functionality was to avoid the big bang approach; refactoring a tonne of code in one go.
The idea with this release is to get people using the new namespaced library/API and nexmo package ASAP. Then we can look at migrating the code within lib/index.js into the appropriate classes.
There won't be anything telling people to do require('nexmo/lib/index/js') (with the exception of this PR thread). As far as anybody using the nexmo package is concerned there is only the new namespaced API.

Agreed. Sounds good. My main concerns would be to simplify the codebase and that involves not promising for old APIs to remain working. Would be good to add a deprecation warning for the OLD API to warn people this won't remain in the version after next.

Would be good to add a deprecation warning for the OLD API to warn people this won't remain in the version after next.

It's JS so there isn't really a good way of doing this.
We could JSDoc the codebase with @deprecated? But that won't trigger any warnings if people try to use them.

console.warn?

console.warn?

We can't use console.warn as the old API is still being used by the new namespaced code. It's just the old API should be classed private.
I kinda think this is a non-issue. If we don't tell people about nexmo/lib/index then the API won't be used. I'd be happy to mark them as @private for anybody delving into the code.

Probably not worth trying to detect how a lib is included. Leave it.

@pvela when you get a moment could you please cast your eyes over this PR?


Retry docker ops on ReadTimeoutError

Note that We have been experiencing ReadTimeoutErrors on push operations. This PR proposes retrying any operation which errors with a ReadTimeout.

Release Notes:

Retry docker operations if a ReadTimeoutError is raised


Optimizing flags

Using SVGO to optimized all flag icons for trimmin' the fat.
This uses the default settings of the tool with the exception of Precision. I tested a few different images using SVGOMG's online tool and using 1 point of precision still maintains high-quality svgs.
Visual inspection of the Flags also shows that they retain quality as per the originals

Great, but instead of keeping them in a separate optimized directory, wouldn't it make more sense to replace the old flags with new optimized ones?

@lipis if you would like me to move the icons I can do this, just lmk

I will add the task at one point.. #395 and I will experiment locally to see if I'll update all the sources.. but for now I'll close this one.. sorry.. too many edits! :)

👍🏻

Thanks,
-e

On Oct 8, 2017, at 4:08 PM, Lipis<EMAIL_ADDRESS>wrote:
Closed #393.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Add an LSP to be able communicate with editors

Hey :wave:
This is an attempt to make the extension available to all editors that support LSP (In my specific case, I'm testing this with Neovim), so that we can close https://github.com/yoavbls/pretty-ts-errors/issues/21 and https://github.com/yoavbls/pretty-ts-errors/issues/26. For now, this is mostly a draft, just to discuss some ideas on how we could make this possible, but hopefully, we can push this forward :smile: .
The initial idea I had was to for now just add an LSP to this repo and call the same methods that the vscode extension calls, but ideally, it would be good to separate the LSP module from the extension module, so that other editors can import only the lsp, but not the vscode extension (and on vscode we can probably just import the methods directly from the lsp package and use them as we are currently using). I saw that there's a PR to transform this repo into a monorepo, so it is also something we could leverage later to separate both modules
I've also created a draft plugin for neovim which uses this LSP (available here), and while it's still far from being usable, we can already get the results from the LSP:

As you can see, there is still one problem which is that Neovim doesn't render HTML nor Markdown on its diagnostics, just plain text, so we would need to also have the option to choose which output type we should return the diagnostics in, when making the LSP call.
My initial idea for that was when calling the LSP from the plugin's editor, we also pass the expected output on the request, then on the LSP we use that and format things accordingly. The downside is that we would need to pass around the output to almost every function, which is a bit annoying.
Another option would be to create providers that exports all the format functions for the particular output type, but that I guess would require a bigger refactor of the codebase.
What do you think?

There already exists a package that aims to do the same and has more complete support for LSP: https://github.com/yoavbls/pretty-ts-errors/issues/21#issuecomment-1925314596

@rchl From what I could see, the ideas in both are pretty different, on my PR the idea is to integrate an LSP into this package, so that it can be used not only by the vscode extension itself, but also any other editor extension, and have an output option, so we can support whatever the editor needs.
On the PR you mentioned, the package is supposed to be a completely separate thing that replaces the HTML rendering that the original package provides with Markdown ones (which I believe is not completely supported by neovim as well, as shown on the screenshot above). It also exposes a CLI that can be interacted with, which could be used by extensions to communicate, but as far as I know, that doesn't follow the LSP convention, so we need to do additional process spawns by ourselves on the editor extension when we need to call the format functions.
Having an LSP is a bit nicer in my opinion, as the editor can spawn the process in the background, keeping it running and then communicate with it via RPC when needed, without needing to spawn new instances on each request (which probably makes it a bit faster too), and I believe that using the standard would make it easier for editors to adopt.

Personally I think this code should be integrated with typescript language servers (like typescript-language-server or coc-server) and not be a separate server. For that, an approach where there exists a package that outputs in LSP-format (like the one I've linked to) is what is really needed. Then it's up to maintainers of those server to integrate with it as an optional feature.
I don't even see how your approach would even be possible in an editor like SublimeText (which I'm using) because that would means that the diagnostics from one server would have to be passed to another server and then shown on hover (and/or diagnostics panel). This doesn't really seem feasible to me.

On the PR you mentioned, the package is supposed to be a completely separate thing that replaces the HTML rendering that the original package provides with Markdown ones (which I believe is not completely supported by neovim as well, as shown on the screenshot above).

LSP spec supports markdown and plaintext only so it makes sense to output in markdown as a main format. Of course it would also makes sense to support plaintext output if neovim doesn't support markdown but is that really the case. The output of that version has made it for neovim in mind as far as I can tell - https://github.com/hexh250786313/pretty-ts-errors-markdown/pull/2#issuecomment-1962822959 (there is mention of it not supporting inline links but code block seem to be supported)

I agree having this integrated directly on typescript-language-server would be the best thing, but I guess this is exactly the reason why pretty-ts-errors exists, to bridge this gap and output errors that are easier to understand. If the errors on tsserver were better formatted, then we wouldn't need any of those packages :smile:

I don't even see how your approach would even be possible in an editor like SublimeText (which I'm using) because that would means that the diagnostics from one server would have to be passed to another server and then shown on hover (and/or diagnostics panel). This doesn't really seem feasible to me.

This seems to be what the VSCode extension does though, from this code, the extension checks the diagnostics when they change, and then formats it, returning new diagnostics (which is why we see two diagnostic errors when we install this extension, as seen on this video).
On my neovim plugin, because neovim exposes apis to control the visibility of all diagnostics, I did a workaround to filter the diagnostics from tsserver that we have already processed, so that we don't show them twice (once from typescript, and the other from pretty-ts-errors).
I'm not sure if theres a better way, other than integrating this directly onto typescript-language-server, as you mentioned before 😕

LSP spec supports markdown and plaintext only so it makes sense to output in markdown as a main format. Of course it would also makes sense to support plaintext output if neovim doesn't support markdown but is that really the case? The author of that version has made it for neovim in mind, as far as I can tell - https://github.com/hexh250786313/pretty-ts-errors-markdown/pull/2#issuecomment-1962822959 (there is mention of it not supporting inline links but code block seem to be supported)

I also assumed it did support markdown as well at first, but when I passed markdown to it, neovim rendered it as plain text, and when searching their docs they don't mention anything, so without looking at the coc plugin (and also by the screenshots he provided), I assume he's not using the standard diagnostics from neovim (probably he's opening a new floating window instead and manually rendering the output there).
I can have a better look into his plugin later though, to confirm this is really the case, thank you for bringing this up :smile:

I agree having this integrated directly on typescript-language-server would be the best thing, but I guess this is exactly the reason why pretty-ts-errors exists, to bridge this gap and output errors that are easier to understand. If the errors on tsserver were better formatted, then we wouldn't need any of those packages 😄

I'm not sure if we are on the same page. The typescript-language-server is not tsserver. It's a third-party LSP implementation that utilizes tsserver. And it makes sense for it to integrate this project as long as tsserver doesn't do that itself.

This seems to be what the VSCode extension does though, from this code, the extension checks the diagnostics when they change, and then formats it, returning new diagnostics (which is why we see two diagnostic errors when we install this extension, as seen on this video).

VSCode is not a great example because it doesn't run tsserver through LSP while other editors do (well, coc-tsserver maybe not).
All we really need here is a package like the one I've linked to that provides a nodejs-level API that returns LSP-compatible output.

@GabeDuarteM

On my neovim plugin, because neovim exposes apis to control the visibility of all diagnostics, I did a workaround to filter the diagnostics from tsserver that we have already processed, so that we don't show them twice (once from typescript, and the other from pretty-ts-errors).

In fact, my coc-pretty-ts-errors supports two modes: one is the one you mentioned, which displays in the diagnostic panel, and the other is similar to the original pretty-ts-errors, which is displayed through the hover function. Displaying in the diagnostic panel is actually just an additional feature. Personally, I prefer to display it on hover, which is why I did not filter the original diagnostic information. I do not want to change anything from the language server; such filtering functionality should be implemented in the language server rather than by the plugin. coc-pretty-ts-errors simply follows the practice of pretty-ts-errors as a VSC plugin. In fact, since the coc.nvim plugin system is a variant of the VSC plugin system, the implementation of coc-pretty-ts-errors is similar to pretty-ts-errors in many aspects. Therefore, I did not consider too much whether my coc-pretty-ts-errors should be a plugin, an LSP, or something else. coc-pretty-ts-errors is just a "replica" of pretty-ts-errors.

Having an LSP is a bit nicer in my opinion, as the editor can spawn the process in the background, keeping it running and then communicate with it via RPC when needed, without needing to spawn new instances on each request (which probably makes it a bit faster too), and I believe that using the standard would make it easier for editors to adopt.

As for pretty-ts-errors-markdown, it is essentially just a formatting tool. You can do anything based on it, including implementing the LSP features you mentioned, or even making it a part of the original pretty-ts-errors. It does not contain any specific 'editor philosophy'.

But not sure if the author of this one wants to maintain a markdown variant in addition to the original one.

I will continue to port new changes from the original until it has its own markdown version.

@hexh250786313 hey, thank you for your input as well! It's nice to see some traction on this issue :smiley:

Personally, I prefer to display it on hover, which is why I did not filter the original diagnostic information. I do not want to change anything from the language server; such filtering functionality should be implemented in the language server rather than by the plugin.

The main reason why I decided to filter the original messages on the diagnostics panel is that otherwise we would have duplicated messages signaling the same thing (and I've seen multiple people commenting negatively about this behavior), and while I agree that being able to control that on the original LSP is the best solution, I don't think we can do that currently, hence the current filter on the plugin. Of course, if needed we can toggle that on/off, I just personally feel like displaying the same error twice is a bit weird

As for pretty-ts-errors-markdown, it is essentially just a formatting tool. You can do anything based on it, including implementing the LSP features you mentioned, or even making it a part of the original pretty-ts-errors. It does not contain any specific 'editor philosophy'.

Because I didn't see a PR about porting your changes to this repo, or discussing the idea of doing that, I imagined you wanted to keep your fork as its own separate thing, which is why I created this one trying to push forward the LSP integration, so every editor can benefit from those features (be that vscode, neovim with the native LSP or with the coc's LSP, sublime, etc).
I believe that having a strong foundation holding the core functionalities and allowing editors to leverage those while implementing editor-specific plugins separately is probably the best bet, and it's actually why LSPs were invented in the first place. By having separate solutions, we will need to worry about keeping both versions up to date with each other, and sometimes that can be a nightmare, especially on big refactors...

As far as I know, the diagnostic panel of builtin-lsp indeed cannot support markdown highlighting. Therefore, I would recommend using the hover feature to integrate pretty-ts-errors. I am not certain about builtin-lsp's support for markdown in hover tooltips, but I believe that any client that has implemented LSP should be able to support markdown highlighting in hover tooltips to some extent, because the information display in hover is inherently designed to support filetype.

Thank you for the tip, depending on how this PR gets handled I can also explore the hover route, although, at least from my usage of nvim, I usually only see diagnostics through the normal diagnostics panel, that way I can see all of them in a single view (eslint, typescript, etc). While I do prefer a lot more having the markdown view, I personally feel like it would be a brittle experience to separate typescript-specific diagnostics under a different keybind than everything else, which is why I believe that supporting the native diagnostics is probably the best move (although I don't mind the option to also allow the custom markdown view)

In any case, I guess we are now mostly discussing plugin-specific topics, but the main idea behind this PR was to try to push forward the idea of having a solution that could fit all editors and discuss how we can implement those flexibly, since currently, we have a solution which is very tailored to vscode, and since this was a highly anticipated feature but with little movement, I decided to give it a shot here

I would very much like the idea of opening this as an LSP such that other editors like Emacs and (neo)Vim can use it.


Event service providers improvements

Description

Improved event service providers to make listeners overridable.
How to test this

I think just need to test all events to make sure that listeners are working
Documentation

[x] My pull request requires a update on the documentation repository.

Hi @ghermans and @k3rnel,
I am checking this will let you know if any changes are required.

I just verified all events by die and dump and it's working fine.


⚠ Bofrost.lu has degraded performance

In 1e553ca, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 3255 ms

Resolved: Bofrost.lu performance has improved in 293e01a after 9 minutes.


Disable linting message by UI

Hi,
would it be possible to add a feature for disabling linting message on request? I quite often write code, that sometimes generates some pylint/flake8/mypy warning, which I am actually aware of, but choose to write it in such a way anyway.
Then I have to manually add a comment such as # pylint: disable=unused-argument to the end of such line to suppress warning on that particular line.
would it be possible to have a button/context menu for each warning (and obviously not anything worse than warning) to add such a comment automatically?
Thanks

Hello @otaj , thank you for reaching out.
As you can see here, there are quite a number of pylint messages, and adding a button for every single one of them wouldn't be feasible.
Have you taken a look at settings like python.pylintArgs where you can specify which messages to ignore? Here's the extension documentation, and a relevant Stack Overflow question.
In any case, this issue is now marked as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes your idea gets to help us make our decision.

Hi,
I don't think you quite understood what I meant. I did not mean to add a button for every single type of warning message pylint could possibly produce, that would be pointless. What I meant was that on every instance of warning, it would be nice to selectively silence it.
Of course, I know about the option to silence some type of warning messages, but I would still like to keep those warnings, they often prove useful, unless I explicitly know, what I am doing and explicitly silence the warning.

We get questions and requests from a wide variety of users, some of them absolute beginners and others like you who are more comfortable with Python and the extension, so I was simply pointing out existing options 🙂
In your case, you mean something like a quick fix suggestion which would add a # pylint: disable=something comment (with a TypeScript example here)?

Exactly! Ideally only for the specific line, not globally for a file.

Thanks for the suggestion 👍 but we decided not to move forward with this idea for now.


builtin.buffers() does not show hidden buffers when reopening a Session

Steps to reproduce

Open some buffers, some of them hidden, some of them in the current window.
Save current session (I use tpope's vim-obsession plugin) for this (:Obsession)
Close nvim
Reopen session with nvim -S
:lua require'telescope.builtin'.buffers()

Actual behavior
telescope does not show hidden buffers, only lists buffers currently visible.
Expected behavior
telescope should list all buffers, hidden or not.
As a comparison, this is the behavior of :Buffers in the fzf.vim plugin

Hey thanks for the report. #32 added this behavior with an opt variable and is documented here.
Basically you would run lua require'telescope.builtin'.buffers{ show_all_buffers = true }.
Currently the opt default is false but we could change that depending on how @tjdevries feels about it.
Let me know if this works. I have not tested it with vim-obsession.

Hey thanks for the report. #32 added this behavior with an opt variable and is documented here.
Basically you would run lua require'telescope.builtin'.buffers{ show_all_buffers = true }.
Currently the opt default is false but we could change that depending on how @tjdevries feels about it.
Let me know if this works. I have not tested it with vim-obsession.

It works, thanks.

Currently the opt default is false but we could change that depending on how @tjdevries feels about it.

Just leaving my 2 cents here @tjdevries : defaulting this option to false does not make sense to me. If the buffers are visible, one can just navigate to them. One upside of a buffer-based workflow (instead of using tabs like in other editors) is that one could have hundreds of hidden buffers and still navigate through them seamlessly.

I see what you're saying.
For now I think I will leave it as is. At some point, I may add more easy default configuration for people for this, but I have some bugs I have to fix first :laughing:


Fixes a typo in permissions.go

Current coverage is 48.32% (diff: 0.00%)

Merging #315 into master will not change coverage

@@             master       #315   diff @@
==========================================
  Files            33         33
  Lines          1223       1223
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            591        591
  Misses          592        592
  Partials         40         40

Powered by Codecov. Last update 571d7ff...6d99f90


pigpio for Allwinner A20 ou H3

Hi,
I'm using pigpio for a long time with my raspberry pis, For various reason I also use Orange Pi (Allwinner H3) / Banana Pi (A20) and I'm really missing pigpio. pigpio is compiling perfectly on both but I never tried to use it fearing to damage my boards (as many GPIO are in use).
So I have two questions :

What could I do to support other board ? is there a file in particular to modify ? Are you interested in it ?
I decided to write this issue after spending 2,5 hours to translate a python program reading a si7021 through i2c using pigpio (on an old Raspberry pi) to a simple python script using smbus and I had to keep only temperature / humidity readings, everything else was erroring. Am I taking a risk if I only use pigpio only for it's i2c primitives ? and spi ?

Thanks in advance.

The interesting stuff pigpio does requires DMA, in particular the ARM DMA hardware build into the Broadcom SoCs used by the Pi.
The DMA support is used to provide the high rates of multiple GPIO sampling, waves, and software serial output.
Ordinary SPI, I2C, and serial were very much an afterthought and were principally added to make that functionality if the Pi was being controlled over a network.
Changing SPI and serial to use a a different platform are pretty much name change edits.
I2C is similar, most of the functions are direct implementations of standard Linux SMBus commands.  Again just a name change edit.  Two exceptions are i2c_device_read and i2c_device_write which talk directly to the Linux I2C device (normally /dev/i2c-1).  They can be converted to standard Python if the ioctl module is used.
Unless a clone has a Broadcom SoC I see little possibility of a port.

Thanks a lot for your answer. I guess I'll continue to use C with my Allwinner stuff, Fast Python will be a Raspberry thing ;)
Thanks again


Add R package port of ucimlrepo

Hi 👋
Thanks for making available the Python variant to download data sets off of the UCI ML Repo.
I took a moment to port of the existing code functions into an R package that you can access here:
https://github.com/coatless-rpkg/ucimlrepo
Would it be possible to create a mono repo that includes both the R and Python versions of the package? Also, would you be okay with adding an R data import tab to the website?
Demo
Install the R ucimlrepo package
install.packages("remotes")
remotes::install_github("coatless-rpkg/ucimlrepo")

Import the dataset into your code
library(ucimlrepo)

# fetch dataset
iris <- fetch_ucirepo(id = 53)

# data (as R dataframe)
X <- iris$data$features
y <- iris$data$targets

# metadata
print(iris$metadata)

# variable information
print(iris$variables)

Good one. Thumbs up