Peering IP Change RJ Huge-Networks

Full Name
Renato de Oliveira Jucá
ASN
264409
PeeringDB Integration

[X] My PeeringDB Entries are current
[ ] Peer at ALL EXCHANGES (and skip the Peer Address(es) field below)

Peer Address(es)
Hello Routeviews Team,
I would like to reconfigure our Peering in RJ, Please use the news IPs.
IPv4: <IP_ADDRESS>
IPv6:  2001:12f8:0:2::55:6
Best Regards,
Renato Jucá
Multihop

[ ] Multihop Peering Request

Code of Conduct (TODO)

[X] I agree to follow this project's Code of Conduct

IPs have been changed.
 Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
 <IP_ADDRESS>       4     264409     14833        39        0    0    0 00:18:23        48679        0 Huge Networks -

 Neighbor              V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
 2001:12f8:0:2::55:6   4     264409     53640        39        0    0    0 00:18:23       161727        0 Huge Networks -


Syntax Highlighting not working

Hi,
Not sure if this is an issue with Todo MD or something else - but I can't seem to get syntax highlighting to work?
I set todo.md as my default file, and it shows up in the webview/changes are synced, but there's no syntax highlighting at all in the text file.
Also, not sure if this is related, But the webview doesn't update when I edit the default file also, I've opened a separate ticket for that
https://github.com/usernamehw/vscode-todo-md/issues/29

Does it make any difference if the file is named todo.md (lowercase)?

Changing the case didnt work because NTFS\Windows is case-insensitive so the old name seemed to be cached
But adding "TODO" to the glob pattern worked! That seemed to be the issue, thanks :)
Maybe the default on windows should be making this case insensitive? I think glob behaves that way by default in some languages.

This extension is using built-in vscode api and in vscode Glob matching is case-sensitive https://github.com/microsoft/vscode/issues/10633.
I don't think it's something that makes it worth of importing another library.


Warn users about putting frozen actions

related to #1254

This error message also occurs if you accidentally put a string (like a redux type constant) instead of a redux action (object with type property). Not really anything actionable, just saving other users from making the same mistake I did by posting here.


fix issue with optionality of CompilerHost

fixes regression introduced in  #7775 and found by @jbrantly

Tests fail because of tslint (whose failure is caused by the bug fixed in this PR) pinging @mhegazy

:+1:


"theme" not usable in CodeController

I am not able to use the CodeController's option to add a theme. Here is my issue

My error message: The named parameter 'theme' isn't defined.
Try correcting the name to an existing named parameter's name, or defining a named parameter with the name 'theme'.

@CodingSmiles  Is there a solution to this error?

Replying to myself here, I did a little bit of work and made it work
[image: image.png]
Sorry if I'm doing it wrong or nobody asked about this.
On Tue, Oct 3, 2023 at 2:30 PM Aadiraj Anil @.***>
wrote:

I can't see this comment on Github, so I'm replying with an email.
Unfortunately, I don't know any solutions to the error. There must be
something but I'm definitely not the right person to ask this to. I left
that project months ago now 😅
On Tue, Oct 3, 2023 at 11:30 AM SunMin,Kim @.***>
wrote:

@CodingSmiles https://github.com/CodingSmiles Is there a solution to
this error?
—
Reply to this email directly, view it on GitHub
https://github.com/BertrandBev/code_field/issues/77#issuecomment-1744262270,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW2BCF6HGED7T72RMXMVZ3LX5OSZLAVCNFSM6AAAAAAYB5E6EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUGI3DEMRXGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Replying to myself here, I did a little bit of work and made it work [image: image.png] Sorry if I'm doing it wrong or nobody asked about this. On Tue, Oct 3, 2023 at 2:30 PM Aadiraj Anil @.> wrote:
…
I can't see this comment on Github, so I'm replying with an email. Unfortunately, I don't know any solutions to the error. There must be something but I'm definitely not the right person to ask this to. I left that project months ago now 😅 On Tue, Oct 3, 2023 at 11:30 AM SunMin,Kim @.> wrote: > @CodingSmiles https://github.com/CodingSmiles Is there a solution to > this error? > > — > Reply to this email directly, view it on GitHub > <#77 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/AW2BCF6HGED7T72RMXMVZ3LX5OSZLAVCNFSM6AAAAAAYB5E6EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUGI3DEMRXGA > . > You are receiving this because you were mentioned.Message ID: > @.***> >

Your image isn't showing. How did you get themes to work?

So instead of returning a CodeField:
return CodeField(
    controller: _codeController!,
    textStyle: TextStyle(fontFamily: 'SourceCode'),

  );

We need to return a CodeThemeData with the CodeField as a child:
return CodeTheme(
    data: const CodeThemeData(styles: monokaiSublimeTheme),
    child: CodeField(
      controller: _codeController!,
      textStyle: const TextStyle(fontFamily: 'SourceCode'),
    ),
  );


tlogserver: handle slave server failure

The tlogserver should notify the 0-Orchestrator using the logger implemented in #300, in case a server on the slave cluster of a vdisk has failed.
Remaining Questions:

What to do with the data in the meanwhile? Do we simply forget about it, or where do we write it to if we can't write it to the server wanted to write it to?

What to do with the data in the meanwhile? Do we simply forget about it, or where do we write it to if we can't write it to the server wanted to write it to?

 It will continue the sync based on tlog data, starting from the last sequence synced

Still need to completely design self healing for tlogs. Things like maintenance, repair, ..., still all need to be taken care of

Once #455 is clearly defined and https://github.com/zero-os/0-orchestrator/blob/master/specs/selfhealing/storage.md is accurate as well, we'll also have to work out the exactly implications for this part of the issue. It is already discussed in https://github.com/zero-os/0-orchestrator/blob/master/specs/selfhealing/storage.md#ssd-failure-in-slave-storage-cluster, in a vague way.
But what will probably happen is that when the tlogserver gets a connection problem with a slave server, it will:

Mark that server as offline, and notify the upper layer using the https://github.com/zero-os/0-Disk/blob/master/docs/log.md#ardb-storage-server-issues message;
It will send a message to the tlogclient such that the nbdserver can see that a slave server is offline, such that from that point on, we'll keep a list of blocks we write to the primary server, in that server;
Once the upper layer has decided what to do we either repair or respread that data from the primary cluster to the slave server such that the normal tlog-syncing for that shard index can happen again;

Step (2) of this flow however is broken though, as there is a time gap between the point that the slave server goes offline and the point where the vdisk (running in the nbdserver) knows about it. Still need to work out this issue in detail with this (and perhaps others) imperfections/errors worked out.

Step (2) of this flow however is broken though, as there is a time gap between the point that the slave server goes offline and the point where the vdisk (running in the nbdserver) knows about it. Still need to work out this issue in detail with this (and perhaps others) imperfections/errors worked out.

I had made an issue for it #469, but closed it again, as I no longer think this is an issue. If it does become an issue as originally thought we can re-open that issue again.


TSS2 RAV4 firmware versions

update fingerprint for Car.RAV4_TSS2.

Please also include the dongleID from the device this change came from (Settings -> Device -> DongleID)

Please also include the dongleID from the device this change came from (Settings -> Device -> DongleID)

Which file or place should I put the dongleID?

Just post the dongleID here in the comments

Just post the dongleID here in the comments

dongleID: 7c8e5c7cebab8bc9
if this is good for u to accept the firmware ID? Or I will create another pull!

Update this PR with the above changes.

dongleID: 7c8e5c7cebab8bc9

Merged! Thanks for the pull request!


Include GIS tests in check target

This doesn't actually add much value and makes the test suite much to finicky. We already test our GIS functionality separately anyways.


19.03: openjpeg: CVE-2019-12973

(cherry picked from commit 011dc3701840574d47808b0708320b23d22deae3)
Motivation for this change
Fixes #64182.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Pushed as 938c15b94a.


Monitor physical size in Windows 7 and later

For Windows 7-8 and maybe XP but Excluding 8.1 GetDeviceCaps do not return the correct values.
There is a way to get the correct values in all versions of Windows albeit in a hacked way. This is documented in the sites below using C++.
http://ofekshilon.com/2011/11/13/reading-monitor-physical-dimensions-or-getting-the-edid-the-right-way/
http://ofekshilon.com/2014/06/19/reading-specific-monitor-dimensions/
I ported the code to C but did not clean it up all the way yet. However because this is a hack and should not be rely to be consistent it would handy to have an option in CMake to enable it.
https://github.com/bornskilled200/dpi

It does not produce correct sizes for me either. It says my monitor is 903x508 mm, but it's closer to 600x340...

Well let us get all the facts straight to make sure of everything.
Some things to note, GetDeviceCaps in 8.1 and my current method relies and EDID data from the monitor to give back the correct measurements of the monitor. This is not always reliable.
This was done on an Windows 8.1 machine.
Output from tests/monitors
Name: Generic PnP Monitor (primary)
Current mode: 1920 x 1080 x 24 (8 8 8) 60 Hz
Virtual position: 0 0
Physical size: 531 x 299 mm (91.84 dpi)

Name: Generic PnP Monitor (secondary)
Current mode: 1920 x 1080 x 24 (8 8 8) 60 Hz
Virtual position: 1920 0
Physical size: 476 x 268 mm (102.45 dpi)

Name: G215H (Digital) (secondary)
Current mode: 1920 x 1080 x 24 (8 8 8) 60 Hz
Virtual position: -1920 0
Physical size: 477 x 268 mm (102.24 dpi)

Output from my hack
Generic PnP Monitor: width: 531, height: 299
Generic PnP Monitor: width: 476, height: 268
G215H (Digital): width: 477, height: 268

All of this is a neatly in a table

Windows 8.1
tests/monitors (mm)
hack (mm)
measured (mm)

Monitor 1
531 x 299
531 x 299
525 x 300

Monitor 2
476 x 268
476 x 268
475 x 275

Monitor 3
477 x 268
477 x 268
475 x 265

In the end I expect these measurements to wildly differ on the other versions of Windows.

Related to this, please check out the per-monitor-dpi branch for an attempt at Windows 8.1 per-monitor DPI support. I don't have a Windows 8.1 machine myself, so any testing would be most appreciated.

Got the same result, which is the correct result.


Create a JSP page

-[ ] JSP page should be enabled for given rest call  /randomQuote
-[ ] Page should provide Quote in center of the Page with current date and Author

Invalid


failed to connect redis - WRONGPASS invalid username-password pair

PGSync version:
1.1
Postgres version:
12
Elasticsearch version:
7.6.2
Redis version:
Python version:
3.7
Problem Description:
docker-compose airbnb example is not working`
Error Message (if any):
Traceback (most recent call last):
  File "examples/airbnb/schema.py", line 130, in <module>
    main()
  File "/usr/local/lib/python3.7/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "examples/airbnb/schema.py", line 125, in main
    teardown(config=config)
  File "pgsync/helper.py", line 44, in pgsync.helper.teardown
  File "pgsync/redisqueue.py", line 33, in pgsync.redisqueue.RedisQueue.__init__
  File "/usr/local/lib/python3.7/site-packages/redis/client.py", line 1351, in ping
    return self.execute_command('PING')
  File "/usr/local/lib/python3.7/site-packages/redis/client.py", line 875, in execute_command
    conn = self.connection or pool.get_connection(command_name, **options)
  File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 1185, in get_connection
    connection.connect()
  File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 561, in connect
    self.on_connect()
  File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 637, in on_connect
    auth_response = self.read_response()
  File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 752, in read_response
    raise response
redis.exceptions.ResponseError: WRONGPASS invalid username-password pair

This has now been resolved in release 1.1.1

closing issue. fixed in 1.1.1


Add missing paginator definitions for CloudFormation

This adds the missing pagination definitions for the CloudFormation APIs, as described in #1462.
I've tested DescribeChangeSet and ListChangeSets and both work as expected after this change,
client = boto3.client('cloudformation', region_name='eu-west-1')

paginator = client.get_paginator('list_change_sets')
page_iterator = paginator.paginate(StackName='MyStack')

for page in page_iterator:
    print(page)

Codecov Report

Merging #1594 into develop will decrease coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #1594      +/-   ##
===========================================
- Coverage       92%   91.97%   -0.04%
===========================================
  Files           50       50
  Lines         9110     9110
===========================================
- Hits          8382     8379       -3
- Misses         728      731       +3

Impacted Files
Coverage Δ

botocore/credentials.py
98.4% <0%> (-0.4%)
:arrow_down:

Continue to review full report at Codecov.

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

All of these look good except for DescribeChangeSet. That operation has quite a few fields in the output in addition to the Changes result_key. I'm pretty sure they could all be added as non_aggregate_keys, but a couple of them are lists which is making me a little hesitant right now. I'd need to first confirm that the auxiliary lists are also not paginated.
We would need to ensure that all output keys are accounted for, otherwise they'll be dropped from build_full_results output, which in turn effects the CLI in a backwards incompatible way.

Merged in https://github.com/boto/botocore/commit/3b2a60b963bc48a41ecfc9d9f010a976c592f0bc


Template string has extra -'s

Describe the bug

If I run terraform-docs from the CLI, it generates an output file whose headers, footers read <!-- BEGIN_TF_DOCS --> and <!-- END_TF_DOCS --> respectively. However, the GitHub action expects headers, footers <!--- BEGIN_TF_DOCS ---> and <!--- END_TF_DOCS ---> respectively. Note the extra - characters. This causes the sed command (https://github.com/terraform-docs/gh-actions/blob/main/src/docker-entrypoint.sh#L150) to fail to match previously CLI-generated docs and so the github action never actually updates anything.
In short, this means that docs have to either all be generated from the CLI or generated from the github action. I cannot generate docs initially and then expect the action to take care of things moving forward, which is what I would expect.
How can we reproduce it?

In a new or suitable test repo:

Populate files:

echo 'resoure "null_resource" "this" {}' > main.tf

mkdir -p .github/workflows
cat <<- "EOF" > .github/workflows/main.yml
on:
  - pull_request

jobs:
  docs:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.ref }}

    - name: Render terraform docs and push changes back to PR
      uses: terraform-docs/gh-actions@main
      with:
        working-dir: .
        output-file: README.md
        output-method: inject
        git-push: "true"

    - name: Check outputs
      run: |
        git status --porcelain
        cat README.md
EOF

Generate a README.md

terraform-docs markdown table . --output-file=README.md

Git add, commit, and push everything
On a new branch, update main.tf

echo 'resource "null_resource" "this2" {}' >> main.tf

Update README.md

terraform-docs markdown table . --output-file=README.md

Note the difference

git diff

Git add main.tf only. Commit and push
Open a PR
Check the results. The last step should print the contents of README.md, which have not been modified.

Environment information

terraform-docs version (use terraform-docs --version): terraform-docs version v0.15.0 darwin/amd64
Go version (if you manually built. use go version): installed with Brew
OS (e.g. Windows, MacOS): MacOS

This was due to disparity of terraform-docs and the actions in regards of the content template, which was fixed and unified in #46, and will be available in the upcoming v1.0.0 release.


[AL-2227] Commit level info

🚀 🚀 Pull Request
Checklist:

[ ]  My code follows the style guidelines of this project and the Contributing document
[ ]  I have commented my code, particularly in hard-to-understand areas
[ ]  I have kept the coverage-rate up
[ ]  I have performed a self-review of my own code and resolved any problems
[ ]  I have checked to ensure there aren't any other open Pull Requests for the same change
[ ]  I have described and made corresponding changes to the relevant documentation
[ ]  New and existing unit tests pass locally with my changes

Changes

Store commit level info as backup in case version control info gets corrupted / missing.
fix_vc method for dataset to force rebuild version control info.

@FayazRahman How does the user load the dataset so they can run fix_vc if the version control info is missing?

@istranic We will automatically rebuild version control info in case version control info is missing / corrupted. fix_vc is just a method to force the rebuild, the user will almost never have to use this.

@FayazRahman  It still feels a bit scary to do this without the user awareness. Are you sure it's not possible to end up in an even worse state if we run fix_vc, compared to the state prior to running it? Is it possible fix_vc would run by accident and break something when nothing was broken prior?

@istranic We only rebuild the version control info automatically if load_version_info fails, i.e, when the dataset cannot be loaded or even reset. So rebuilding version info is the only choice as it can't get any worse than not being able to load or reset the dataset. (Just to be clear, we don't really call fix_vc internally but another function that does it)


bosun: denormalizing tsdb metrics in relay

opentsdb metrics with high tag cardinality have poor query performance. This allows the tsdb relay to denormalize and duplicate data based on tags.
It can transform os.mem.used{host=web01} to __web01.os.mem.used{host=web01} so that queries can use the much lower cardinality metric. Tags, Timestamps and Values will be unchanged in denormalized metrics.
Current configSyntax = -denormalize=metric1_someTag,metric2_host_cpu. Allow multiple metrics and multiple tag potentially per metric.

Review status: 0 of 7 files reviewed, 7 unresolved discussions, some commit checks failed.

cmd/tsdbrelay/denormalization.go, line 33 [r3] (raw file):
denormalizationRules is a var, not a type.

cmd/tsdbrelay/denormalization.go, line 52 [r2] (raw file):
not really, the tag string is built from the tag values in the particular data point.

cmd/tsdbrelay/main.go, line 23 [r3] (raw file):
testing purposed. will change.

cmd/tsdbrelay/main.go, line 27 [r3] (raw file):
Done.

cmd/tsdbrelay/main.go, line 136 [r1] (raw file):
Done.

cmd/tsdbrelay/main.go, line 178 [r1] (raw file):
Done.

Comments from the review on Reviewable.io

LGTM

opentsdb metrics with high tag cardinality have poor query performance.

@captncraig is there any detailed perf data or suffering sightings for this?


Linux compatibility

Context 🕵♀
According to this task the only blocker to have support for Linux has been fixed.
What 🌱
Make xcodeproj Linux compatible.
Proposal 🎉

Set up the CI pipeline to run on Linux.
Check out and fix any other issues with the usage of Foundation APIs.

 Linux compatibility

Since the board is not public, I can't see the current progress on this one. I'd love to see Linux compatibility for xcodeproj. Currently it's not compatible, as you can see here my Linux CI builds are failling with this error:
/bitrise/src/.build/checkouts/xcodeproj.git--1264315860731431102/Sources/xcodeproj/Extensions/OSLog+Extras.swift:2:8: error: no such module 'os.signpost'
import os.signpost
       ^

Hey @Dschee. Sorry, we stopped using Trello. We can wrap that one to run only on macOS. The main blocker is the PropertyListSerializer, which is not available on Linux. They don't seem to have done any work on the ticket that we opened

From the log @Dschee posted it looks like the signposting isn’t available on Linux either

@y-matsuwitter funded this issue with $30. Visit this issue on Issuehunt

I was working through this a bit. Some of these issues are workable, some will take some bigger rethinking.
The os.signpost issue is just for logging, so wrapping all those references with an #if os(macOS) works fine, for some reason canImport doesn't seem to work with SPM.
I was able to just copy the PlistSerializer file from Foundation and seems to compile fine as long as you add in an extension for the _typeMismatch function.
The bigger issue is the class PBXObjectReference: NSObject, Comparable, NSCopying, since none of the ObjC runtime is available for use on Linux.

I'm pretty experienced with doing Swift on Linux on Travis, so ask if you need help. I'm not familiar with Circle though.

Will probably take you up on that @mxcl! I'm familiar with Circle, not terribly difficult to spin up a Linux job using the Swift Docker image on it.
Weirdly, most of the difficulty is around all the isEqual functions. I'll at least get as far as I can and potentially throw up a draft PR when I've got some time later this week.

Poked around a bit more, last remaining thing looks like finding a replacement for  NSPropertyListSerialization that will work on Linux since PropertyListSerialization doesn't seem to port to Linux yet.

Sorry I haven't posted any updates here. The last time I gave this a try I managed to solve the issue of PropertyListSerialization not being available on Linux. I copied the implementation of the serializer over to the project and the compiler seemed happy about it.
Moreover, I had to add some macros around this class, which are only available on macOS.
After all that, I ran into some compilation issues that were hard to debug. If you would like to give it another try it'd be cool.

The macros around logging are fine, some stuff around a String/CVarArgs thing (not sure if this was ever fixed on Linux) but probably can be fixed with an overload.
Copying the implementation works fine for PropertyListEncoder and PropertyListDecoder but not for PropertyListSerialization, although it does look like the functionality is there in the swift-corelibs-foundation implementation? (https://github.com/apple/swift-corelibs-foundation/blob/swift-4.2-branch/Foundation/PropertyListSerialization.swift). I might be reading that wrong though, haven't done much with this.

Unfortunately it's the changes in this guy: https://github.com/tuist/xcodeproj/pull/365/files#diff-acb4ac63a93e60e6a26182f29ed8c02cR84 that are making this more difficult.
Was able to cover all the other errors here: https://github.com/thedavidharris/xcodeproj/commit/0251a7837727bf231ee5277b861316a36f3b2ef7. Tests still pass, although I need to verify that removing all the NSObject/isEqual behavior was done correctly.

Perhaps you can use some alternative PropertyListSerialization.
For example SWXMLHash or Kanna
@thedavidharris  I can fix some issues for Linux support. Where exactly are the problems?

It'd be awesome if you could give a hand to @thedavidharris to make a choice on the serialisation library. Looking at the ones that you shared I'd avoid Kana because it requires some libraries being available in the system. That makes the usage of the library a bit inconvenient.
Another interesting area to tackle given that we are doing all these refactorings is having some performance tests in place. It's possible with XCTest but I wonder if we could publish those number somewhere and compare them in every PR to notify authors about regressions.

Might be best to just consider Linux compatibility when addressing https://github.com/tuist/xcodeproj/issues/369 and that could replace some of the problematic code.
@CognitiveDisson I put up a draft PR at https://github.com/tuist/xcodeproj/pull/370 if you're willing to take a look. Not content with the current cleanliness of it, but it at least shows how to address most of the issues if you have suggestions for better ways to tackle them!


wrong timer setting ?

# Number of minutes between automatic backups. Setting to zero will disable automatic backups
# Min: 0
# Max:<PHONE_NUMBER>
I:backupInterval=60

Is set to 60 but server appears to save every 30 minutes, will test further with double the value.

/backupsmod listbackups
[01:38:18] [Server thread/INFO] [minecraft/DedicatedServer]: 2020/6/3-24:59:33 (38 minutes, 45 seconds ago)
[01:38:18] [Server thread/INFO] [minecraft/DedicatedServer]: 2020/6/3-1:29:32 (8 minutes, 46 seconds ago)

This should be fixed in 1.5.6.


Signature 'Stefan Friese'

Description
Sign the Minimum Viable CD.
Type of change

[x] Signature

Thanks - it is nice to be part of the list of CD supporters :-)


Minor api-reference link fixes

To properly jump to current version of api-reference.

[x] CHANGELOG updated or not needed
[x] Documentation updated or not needed
[x] Haddocks updated or not needed
[x] No new TODOs introduced or explained herafter

not planned


two way bings in vue2.0

when i try to assign some text in content, the console said that
" Error in callback for watcher "content": "

i try use "content.sync" before, but it dosen't work in Vue2.0
Is there any way to solve it?

same problem here

Please use version 1.0.0 !
Two way binding already had removed by vue2.0 .You can sync content through  the change event on editor component,now.

I'm using 1.0.0, but still got this problem. Could you please provide a sample code? Thanks.

See the examples. https://github.com/PeakTai/vue-html5-editor/tree/master/example


Update VS test tools used by action

The VS test tools used by this action are a fixed download from https://aka.ms/local-worker-win-x64. This needs to be updated to support as the version for VS 2019 is missing assemblies.

agreed! the Azure DevOps equivalent is miles ahead of this. Runs with that, against the same code base succeed while this one generates failure because the version is not up to date. will add example error messages tomorrow.


 It is only used when linking a main executable
ld: warning: ignoring file $BUILD_PREFIX/lib/libxml2.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

I can't pretend to be an expert at building C libraries, let alone cross-compiling but I think the library should be coming from the host environment (where the OSX-ARM64 version is installed), not the build enviornment ($BUILD_PREFIX), where the OSX-64 version is installed).

@vtraag and @sodre, could you take a look at this as a replacement for #51?  It seems like xmlEntity has a new element in libxml2 2.11 and is seems like OSX-ARM64 isn't finding the right libxml2 shared library without some help.

Thanks @xylar for taking care of this! The next version of the C core of igraph wil contain a similar fix.
@szhorvat, I would be in favour of keeping the patch in place, and not turn off treating warnings as errors. We will clearly know in a next release that the patch has become obsolete, since it won't be compatible with the new release anymore. However, we will most likely forget to turn on treating warnings as errors again in a next release. If we can keep treating warnings as errors this is useful information. If at some point we encounter too many issues with warnings, we can always turn it off.

@szhorvat, I only started figuring this out yesterday pretty late but I appreciate you wanting an issue about this.
@vtraag, I was aware that you are also a developer in the source repo so I appreciate you seeing that the appropriate changes get made there.  I was somewhat counting on that but I'll make upstream issues in the future as well if I make any future PRs to this feedstock.

@vtraag, I'm not a maintainer so you'll have to merge this when you're happy (or wait for @sodre to approve if you prefer.)

I've already made the fix before I saw this thread, https://github.com/igraph/igraph/commit/5ad464be5ae2f6ebb69c97cb0140c800cc8d97d6

@vtraag, I'm not a maintainer

Thanks @xylar! Given your involvement and contributions, shall I add you to the maintainer list?

Sure, you can add me as a maintainer in #53 if you would like to.

Ha, sorry, just already merged #53 before I saw this message. But will add you directly in main.


Lazy Types in JVM Plugin Extensions and Tasks

The extensions (JavaPluginExtension, ApplicationPlugin, ...) and tasks (JavaCompile, JavaExec, ...) for Java/JVM development exist since the early days of Gradle and are in parts still based on "old" concepts. Since the new lazy types in Gradle are now ready to fully replace the old "convention" concept, we can now fully migrate the extensions and tasks to these new concepts.
This will not only lead to a better and more consistent API, but also will simplify the implementation, where currently extensions and conventions exist side-by-side.
Since this changes public API, all changes need to go through a deprecation/incubation cycle:

In a minor release: Introduce new API and build on new lazy types instead of conventions

Introduce new properties to replace the existing getters/setters in tasks and extensions.
Make the existing getters/setters delegate to the new properties.
 Keep backward compatibility by making each existing convention field a convention() for the corresponding property (e.g.: mainClass = objectFactory.property(String.class).convention(providerFactory.provider(convention::getMainClassName))). Conventions then no longer back the extensions directly and can simply be removed in the next major release.

In one of the minor releases after:

Deprecate the getters/setters and de-incubate the new properties.

In the next major release:

Remove the conventions completely and perform other breaking changes (e.g. changes to inheritance hierarchy).

I think it would be good to split this up into several stages. For example, I would perhaps start with just the input and output file properties that are used to wire tasks together in the core JVM plugins. We've already mostly done this but there are a few things to clean up there:

Add a property to processResources (Copy) represent the output directory.
Remove the dependsOn calls that explicitly wire in compile and process resource outputs and wire this via the source set outputs.
Replace the convention mapping with a convention() for the output locations of the JVM tasks.
Deprecate SourceSetOutput.dir(builtBy: x) so as to encourage people to wire in other source set content using Provider<Directory>.

This will make the JVM plugins more reliable when people rewire these input/output relationships or attempt to change the locations at odd times.
Then, some other potential chunks of improvement could be:

Add lazy typed properties for the Java compile properties that you need to use to cross compile, such as options.fork or options.javaHome. This will help build logic (including the JVM plugins in the future) set up cross compilation in a lazy way, and do so in a way that does not invalidate the instant execution cache (for example by eagerly reading a system property at configuration time).
Add lazy typed properties for convention locations, such as the reporting base dir or test results dir. This makes the things that use these conventions more reliable as people reconfigure locations.
Add lazy typed properties so that all convention mappings in the JVM plugins can be replaced with convention(). This allows us to deprecate and remove convention mappings.
Replace the "convention" objects that are attached to source sets to add support for a non-Java language (Groovy, Scala, Kotlin, Antlr, Protobuf, etc) with extensions or a domain object container of languages. This makes the new languages visible to statically typed languages and tooling that makes use of this (Kotlin DSL, IDEA, etc) and allows us to deprecate and remove "convention" objects.
Whatever's left, but I could continue to do this in a use case focused way like the above.

I expect this would help clarify source set dependencies and make it easier to do things like #2137.

Still relevant imho

This falls under the overarching goals of the Provider API migration: https://github.com/gradle/build-tool-roadmap/issues/28
Closing this particular issue for that.


Make it possible to endorse dogmas on non-adjacent boards.

You pay for the parley first before the endorse.


DO NOT MERGE - Site has been updated to account for docs move to flare (P2)

NOTE: DO NOT MERGE UNTIL DOCS SITE IS READY TO LAUNCH
What does this PR do (include background context, if relevant)?
This PR updates the secretless site by removing docs and associated links and updates them to point to the docs site on flare.
What ticket does this PR close?
Connected to #554
Where should the reviewer start?
Navbar and footer
What is the status of the manual tests?
Check to ensure that there is no way to get to previous, in-house docs page from the site. Also check to ensure that there are no traces of docs documentation in repo.
Links to open issues for related automated integration and unit tests
Links to open issues for related documentation (in READMEs, docs, etc)
Screenshots (if appropriate)
Before:

After:

Changes pushed! What do we need the pkg_secretless_plugin_v1.html file for under  docs/generated/pkg_secretless_plugin_v1.html ? It seems to be the only on calling for the docs layout (I have since changed that 'subpages') but it looks empty and funky. Is this what we want? See below:
Pkg Plugin:

Should this be deleted as well?

@sigalsax that page only gets generated when you run ./bin/build_website - try running that and then viewing this branch with bundle exec jekyll serve


Fix velocity state usage in multicopter position control

Describe problem solved by this pull request
We had a crash while using terrain following and I found out that the vertical velocity estimate of the EKF is getting ignored in that configuration. This was introduced in https://github.com/PX4/Firmware/commit/bf4ac7a9d639f26fc7557345a219ffd1bec04764 and I couldn't find a viable use case for doing that at least with the current implementation. Maybe it was rather experimental back then maybe @Stifael could give us some insights.
Describe your solution
While fixing the above root problem I changed three things (3 commits with detailed descriptions):

Still use the vertical velocity estimate from the estimator in terrain following and do not override it with the dist_bottom_rate.
Do not use the vertical velocity estimate if it's flagged invalid. A bug I realized while comparing to the horizontal velocity case in the same function. This probably never showed up because the vertical velocity is almost always valid but in case it's not it would be fatal to feed position control with it.
Reset the velocity derivatives instead of updating them with zero to avoid spikes when regaining the velocity estimate. I found that bug while looking at the update calls since we had the derivative spike problem before with timing issues when switching modes in #13522.

Test data / coverage
Not tested at all yet, I have to follow up with reports. Reveiws and tests are welcome.
Additional context
Here's a screenshot where you see the distance being reported too high up because of this bug: https://github.com/PX4/ecl/pull/706 and since terrain following was enabled the wrong dist_bottom rate was used before the changes in this pr and made the drone go vertically unstable and cut thrust to idle:

Let's delete dist_bottom_rate instead of copying around and logging duplicate information.
https://github.com/PX4/Firmware/blob/f758a9f29df0b13a7fce2c25f4b64f8df56ed12d/src/modules/ekf2/ekf2_main.cpp#L1330

both makes sense to me (replace and remove dist_bottom_rate)

Thanks @Stifael for confirming. I wanted to update that we flew with this change and terrain-following enabled without any problems. Even though we couldn't do the exact same maneuver again I consider it tested.


check MatrixNormal distribution

Check the efficiency of the current implementation of the MatrixNormalPrecision class using the Kronecker product,
and improve it if possible.

Currently, the build-in class MatrixNormalLinearOperator accepts linear operators, instead of matrices as arguments for row-scale and column-scale.
Inside the object, it converts the matrixnormal object into a multivariate normal object using the kronecker product:
https://github.com/tensorflow/probability/blob/e3d67c00ab491f4314a3d3e8c2cde19c8aa7490e/tensorflow_probability/python/distributions/matrix_normal_linear_operator.py#L179
However, when I try to build a distribution that accepts the matrices instead of linearoperator as arguments by inherit from the MatrixNormalLinearOperator like
'class MatrixNormal(tfd.MatrixNormalLinearOperator)'
the following error messages pops up when using the sample methods of the instance
'ValueError: Graph parent item 0 is not a Tensor'

This error might be related to a feature in the build-in MatrixNormalLinearOperator.
In fact, if we run the sample method of the instance built following the example in
https://www.tensorflow.org/probability/api_docs/python/tfp/distributions/MatrixNormalLinearOperator
we also get a warning message:
WARNING:tensorflow:From .local/lib/python3.8/site-packages/tensorflow/python/ops/linalg/linear_operator_kronecker.py:224: LinearOperator.graph_parents (from tensorflow.python.ops.linalg.linear_operator) is deprecated and will be removed in a future version.
Instructions for updating:
Do not call graph_parents.


Recursive traversal of nodes with parent attribute appended each time

Hello,
I am trying to map an XML source to RDF and would like to know how to traverse recursively while keeping track of the parent's attributes each time. In the example shown, I want all Person nodes to be extracted with the name of each parent  node appended to the current node. Considering all parent names is necessary as the node names may not be unique. (See grandChild1 two times in the example)
Note that I do not know in advance how many levels the nesting can go and hence adding one TriplesMap for each level is not a feasible option.
After having gone through the documentation, examples, and test cases, I am not quite sure if this is even possible.
Following are a simplified sample XML, the RML mapping I created so far, the current RDF output generated using RMLMapper, as well as the RDF output I am expecting.
Data
<Root>
    <Person>
        <name>parent1</name>
        <Children>
            <Person>
                <name>child1</name>
                <Person>
                    <name>grandchild1</name>
                    <Children>
                        <Person>
                            <name>greatgrandchild1</name>
                        </Person>
                    </Children>
                </Person>
            </Person>
            <Person>
                <name>child2</name>
                <Person>
                    <name>grandchild1</name>
                </Person>
            </Person>
        </Children>
    </Person>
</Root>

Mapping
@prefix rml: <http://semweb.mmlab.be/ns/rml#> .
@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix ql: <http://semweb.mmlab.be/ns/ql#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix testont: <http://www.example.com/ontology/> .
@prefix : <http://www.example.com/rules/> .
@base <http://www.example.com/instance/> .

:TriplesMapPerson a rr:TriplesMap;
    rml:logicalSource [
        rml:source "recursion_data.xml";
        rml:referenceFormulation ql:XPath;
        rml:iterator "//Root/Person"
    ].

:TriplesMapPerson rr:subjectMap [
    rr:template "{name}"
].

:TriplesMapPerson rr:predicateObjectMap [
    rr:predicate rdf:type;
    rr:object testont:Person
].

:TriplesMapChild a rr:TriplesMap;
    rml:logicalSource [
        rml:source "recursion_data.xml";
        rml:referenceFormulation ql:XPath;
        rml:iterator "//Root/Person/Children/Person"
    ].

:TriplesMapChild rr:subjectMap [
    rr:template "{name}_{../../name}"
].

:TriplesMapChild rr:predicateObjectMap [
    rr:predicate rdf:type;
    rr:object testont:Person
].

Current RDF
<http://www.example.com/instance/parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/child1_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/child2_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.

Expected RDF
<http://www.example.com/instance/parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/child1_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/grandchild1_child1_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/greatgrandchild1_grandchild1_child1_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/child2_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.
<http://www.example.com/instance/grandchild1_child2_parent1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.example.com/ontology/Person>.

I appreciate any assistance in resolving this. Thanks in advance!
Note: I have also asked this question on StackOverflow

Hi and thank you for your interest in RML,
You can recursively extract the names of all ancestor nodes with the XPath expression ancestor-or-self::Person/name. Then you can join these together with the function grel:array_join, as in the attached mapping.
This gives output terms like <http://www.example.com/instance/parent1_child2_grandchild1>. As you can see, the ancestors are in reverse order from the order you desire. You could reverse the order of the array returned by ancestor-or-self::Person/name with an array reversion function. (However, there is no default array reversion function included in the mapper as of now. You could link your own.)
attachments.zip


Add stamina potion for logical Lanayru access

An Unlocked Endurance Potion marco already existed. Changed to used that.

Can you add a changelog change so people know that the logic changed when useing open LMF


Htmlhint v 0.11.0

fixed typing base on #56

I have temporarily  published a new extension  https://marketplace.visualstudio.com/items?itemName=newfuture.htmlhint

OK new extension is published to the marketplace.  Please let me know if anything is broken.

ok, thank you


[question / feature] Allow accessing theme in overrides

I would like to use the theme palette in the overrides section for a theme.
I know this is a bit contradictory, because the overrides are used to create the final theme object, but I would like to use this to write overrides based on the theme palette configuration etc.
For example something like this:
const theme = createMuiTheme({
    palette: {
        // ...
    },
    overrides: theme => ({
        muiButton: {
            // ...
        }
    }),
});

Right now the only solution I see would be separating the overrides into a second call to createMuiTheme which would get the initial theme without overrides as a input.
Would this actually be the recommended way or is there a better solution?

Duplicate of #21757

Duplicate of #21757

@olee Thanks for raising 👍

@olee Thanks for raising 👍

Sorry, didn't find the other issue when searching.
Thanks for pointing me there - keep up the good work @oliviertassinari !!

Sorry, didn't find the other issue when searching.
Thanks for pointing me there - keep up the good work @oliviertassinari !!


Floating precision of rio.transform in Raster.reproject() when passing both dst_bounds and dst_res (or dst_size)

See #356
This specific case is not fixed after #354.

To reproduce the error, with the dataset provided in #354 at this link:
import geoutils as gu
rst = gu.Raster("N62E010_FABDEM_V1-0.tif")
tmp = rst.reproject(dst_crs="EPSG:32633")
test = tmp.reproject(dst_res=(20, 20), dst_bounds=tmp.bounds)
print(test.res)

-> output resolution is (19.99999999999999, 20.0) instead of (20, 20).


Build WASM using docker

Close #239

Merge after #254 gets merged.

@yito88

yeah, I was thinking that same. I think this can be improved by starting from a smaller initial image (at the moment the building image is ubuntu 20.04).
I can try using starting from rust:latest and check if things improve

Using rust:latest it 1.55GB

I'm just trying this and unfortunately the sccache doesn't work with wasm, because the wasm crate use crate-type = ["cdylib"]. It's a known limitation in sccache: https://github.com/mozilla/sccache/blob/3f318a8675e4c3de4f5e8ab2d086189f2ae5f5cf/README.md#rust :(
Also, I think having $(rustup) toolchain install $(nightly) in build-wasm-scripts-docker is not needed, the rust version is set via rust-toolchain file, so the nightly is not going to be used. However the one we have in the root directory has more components than what's needed to build wasm.
I'll open a follow-up to:

remove sccache
move all wasms into a wasm sub-directory and add a rust-toolchain with minimal components


cupsctl --no-remote-any is defunct

On several CUPS versions up to and including 2.1.3, I noticed that
cupsctl --remote-any

will act as expected, but
cupsctl --no-remote-any

fails to reverse the effect. The server stays reachable.
On CUPS 1.7.5: Initial cupsd.conf
Listen localhost:631

[...]

# Restrict access to the server...
<Location />
  Order allow,deny
</Location>

After enabling
# Allow remote access
Port 631

[...]

<Location />
  # Allow remote access...
  Order allow,deny
  Allow all
</Location>

After trying to disable
Port 631

[...]

<Location />
  Order allow,deny
  Allow all
</Location>

only the comments vanish.

Investigating, but this code hasn't changed in a long time... :/

Possibly identified the problem, doing some regression testing...

[master 6720d4f] The --no-remote-any option of cupsctl had no effect (Issue #4866)


chore: updated all dependencies + fix build

Coverage remained the same at 100.0% when pulling aa339ad279094557e3c7faf7840ef9b0f1f84c83 on feature/update-dependencies into b54ba94ac169897eeb8534c7c61134d814d8174e on master.


Test issue

https://github.com/oslabs-beta/VaaS/blob/793263a0dba6b65e1bf2c29a0c6be21613108565/src/client/Components/Home/Home.tsx#L29

Addressing after #94 is complete


same page # id navigation is not working , more over messedup

same page # id navigation is not working , more over messedup by adding a '/' in front of the '#identifier' like
'index.html#/section2'
This doesn't navigate and messing up regular html flow if used ui-router.js

Okay, please set up a plunkr so we can see what's going on and try to find a workaround.

Here,
to make it easy,
How would you do this simple page with ng-ui when I DO NOT WANT TO or NEED TO chop all the < div > into a separate .html file (I really don't understand why should I have to have 100 .html files?)
http://www.codeply.com/render/DRBmOoChfM

This seems to work. If you think its not working properly now, please let me know which part isnt working


Add fidesops as a requirement

Closes #914
Code Changes

[ ] remove shared packages
[ ] add fidesops as a requirement

Steps to Confirm

[ ] all tests pass 👀

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation Updated:

[ ] documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
[ ] documentation issue created (tag docs-team to complete issue separately)

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md

Description Of Changes
Write some things here about the changes and any potential caveats

fideslang==1.0.0 is going to be a problem....

This doesn't really feel like the right way to go about this. If anything, I always imagined that fidesctl would be a dependency of fidesops. The issue or pr don't really address exactly why we are doing this or what problems this addresses.

If fidesops isn't really needed as a dependency and this is only to check compatibility of packages we should be able to add a CI check for it instead. I have some ideas that I think would work.
With either direction this goes I have a question though. Right now this is installing a pined version of fidesops from pypi so if there is a new fidesops release this check may be incorrect. Would it be better to either always install the latest version? Or maybe if this is only to check dependencies install from github main?

sorry folks I should've elaborated here more....
This is going to be a long-lived branch (cringe, I know) that continually checks compatibility with fidesops packages + docker image in preparation for merging the repositories, so this can be safely ignored for now! its just my canary in the coal mine


ruff formatting on save

Ruff includes a new formatter: https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_formatter/README.md
Is there a way to automatically invoke this formatter on save?
I took a stab in the dark and gave these a shot:
  "lsp_code_actions_on_save": {
    "source.lsp_format_on_save": true,
    "source.fixAll": true,
    "source.organizeImports": true,
    "source.applyFormat": true
  },

The documentation you've linked doesn't mention anything about supporting formatting through code actions. It only mentions support "Format on save" LSP functionality which can be enabled with the lsp_format_on_save option in global LSP settings.

@rchl thanks a ton for the quick response.
I've given this a shot in my global LSP settings (started with just the top-level lsp_format_on_save but then tried a couple others just in case:
{
  "log_debug": true,
  "lsp_format_on_save": true,
  "lsp_code_actions_on_save": {
    "lsp_format_on_save": true,
    "source.lsp_format_on_save": true,
    "source.fixAll": true,
    "source.organizeImports": true,
    "source.applyFormat": true
  },
  "clients": {
    "ruff-lsp": {
      "command": [
        "ruff-lsp"
      ],
      "enabled": false,
      "selector": "source.python",
      "initializationOptions": {
        "settings": {
          "args": [],
        },
      },
    },
  },
}

But not seeing my Python code get formatted on save. My JSON code does get formatted on save, so I think lsp_format_on_save is working, just not with ruff.

Gotcha - I filed an issue over there: https://github.com/astral-sh/ruff-lsp/issues/293

Prior to v0.0.41, we gated format capabilities behind an environment variable (RUFF_EXPERIMENTAL_FORMATTER=1), since the formatter was in alpha. The most recent release removes that gating, so v0.0.42 and later should work as expected here.

Got it, thanks @charliermarsh. I submitted a PR to upgrade the requirement to ruff-lsp 0.0.42: https://github.com/sublimelsp/LSP-ruff/pull/42.
Maybe out of the scope of this GH issue, but I noticed that the Sublime plugin is invoking a ruff-lsp that's installed inside the package dir.
LSP: starting ['/Users/sryza/Library/Caches/Sublime Text/Package Storage/LSP-ruff/bin/ruff-lsp'] in /Users/sryza/dagster

Ideally I'd like it to just run using the ruff-lsp command that's installed in my virtualenv. Is there a way to set that up?

Yes. If you run “Preferences: LSP-ruff Settings” from the command palette, you can override the ”command” that’s used to start the subprocess. I recommend not doing that, as server settings may be out of sync.

This method is also mentioned in the readme: https://github.com/sublimelsp/LSP-ruff#configuration


Scaling Issue in cosmograph/react on Safari and Chrome

Hi everyone,
Firstly, I want to express my gratitude for the fantastic work on this library. It's a great resource, and making it open-source is highly appreciated :)
I've been using cosmograph/react, and I've encountered a problem with how nodes and edges scale, specifically in Safari but also in Google Chrome. This issue doesn't occur in my default browser, Arc.
The problem becomes apparent when you zoom in or out on this CodeSandbox example in Safari: https://codesandbox.io/p/sandbox/cosmos-usage-example-forked-kwswkv?file=/src/index.ts
It seems that newer versions of cosmograph have fixed this issue, but the react binding is still on version 1.3.1, where the problem persists.
Could anyone offer some insights or solutions to this?
Thanks,
Jonathan

Thanks @jonsch1 !
Could you please share more details about the scaling issue you're encountering? As a potential solution, you could try using the beta version of the @cosmograph/react library, version 1.4.0-beta.0, which includes a newer version of the @cosmograph/cosmos library.

Thank you for the quick response! So, i tried the 1.4.0 beta version, but it didn't help.
Here is a more detailed explanation and image of the scaling issue:
When zooming in from a high distance, nodes grow until they reach their maximum size. Further zooming in won't change the node size, as they shrink to maintain their relative size.
However, when opening the visualization in Safari, it seems that the maximum node size is much larger, which reduces the visualization's effectiveness when zooming in to focus on a group of nodes.

@jonsch1 Thanks for providing the example!
Different hardware and browsers can have different maximum point size limit which makes it a bit difficult to adapt to. We're thinking about implementing a new point sizing strategy on zoom and will keep you posted. Most likely that will happen closer to summer.

@jonsch1  You can alternatively disable the resizing of nodes on zoom by setting the config option zoomNodesOnZoom to false.

Thank you all for the answers!! @Stukova Thank you for the suggestion, although I wouldn't want to disable the resizing I think. The option zoomNodesOnZoom seems not to be available in the current react version (1.4.0 beta). In general if I want to have the quickest access to new features it probably makes sense to use the typescript vanilla version, right? :)

@jonsch1 Sorry, my mistake, not zoomNodesOnZoom, but scaleNodesOnZoom 🤦♀ Should work with react too.

That works, thanks!

So, setting scaleNodesOnZoom to false and setting nodeSize to 20 actually solves my cross-browser scaling issue. So i wouldn't mind if you close this issue. :)


canMakePayment always return false

Hi,
I'm trying to understand why canMakePayment always return false although I have setup a card in the browser. (When testing locally it always return true).
I configured a Visa test card in Chrome<PHONE_NUMBER>111111 and also a real mastercard.
I'm attaching the browser console. Am I doing something wrong? Is there a problem maybe?
const methodData = [{
        supportedMethods: "basic-card",
        data: {
            supportedNetworks: ["mastercard","visa"],
            supportedTypes: ["debit", "credit"]
        }
    }
];
const details = {
    total: {
        label: "Total due",
        amount: {currency: "USD", value: "10.00"}
    }
};
var request = new PaymentRequest(methodData, details);
PaymentRequest {id: "c12d264e-f677-49c8-b050-2252e38f5e24", shippingAddress: null, shippingOption: null, shippingType: null, onshippingaddresschange: null, …}
request.canMakePayment().then((result) => {
console.log(result);
});
Promise {<pending>}
__proto__: Promise
[[PromiseStatus]]: "resolved"
[[PromiseValue]]: undefined

false

The problem was an invalid SSL certification.
I'm closing the issue.


fix: declarative config test comment(USED FOR TESTING, DO NOT MERGE)

Description
Currently this PR is used for testing declarative config test
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/test gke-qa-e2e-tests

/test ocp-4-10-merge-qa-e2e-tests

/test ocp-4-12-qa-e2e-tests

/test ocp-4-13-qa-e2e-tests

/test ocp-4-10-qa-e2e-tests

/test ocp-4-10-qa-e2e-tests

/test gke-qa-e2e-tests

/test ocp-4-13-qa-e2e-tests

/test gke-qa-e2e-tests
/test ocp-4-12-qa-e2e-tests

/test ocp-4-10-qa-e2e-tests

/test ocp-4-13-qa-e2e-tests

/test gke-qa-e2e-tests

/test ocp-4-10-qa-e2e-tests

/test ocp-4-10-qa-e2e-tests
/test ocp-4-12-qa-e2e-tests
/test ocp-4-13-qa-e2e-tests
/test gke-qa-e2e-tests

/retest


chore(localizations): Update he-IL

Description

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[x] other:

Hi @tmilewski ,
I’m glad that my contribution was helpful. I appreciate the opportunity to be involved with Clerk and look forward to working on more improvements in the future.
Best regards,
@develad


[homebridge-weather-plus] Could not retreive weather report with API 3.0, trying API 2.5 now ...

Hi, I encountered the error below in HomeBridge, and I have double checked API key which look correct to me.
[homebridge-weather-plus] Could not retreive weather report with API 3.0, trying API 2.5 now ...
Maybe openweathermap changed their API recently? Anybody else experience the same?

The same with me.

Same issue here

Same issue here

You need to subscribe to the One Call API to get the 3.0 access.
The first 1000 calls to openwethermap per day are free.  You can limit the daily accesses to 1000 to prevent being charged at all.
Once your account has. been updated to the 3.0 subscription, again free if you limit the daily accesses, you won't see that message in the logs anymore.

A log line of:
[homebridge-weather-plus] Could not retreive weather report with API 3.0, trying API 2.5 now ...
is ok. It means that it failed to fetch your data from 3.0 API, and is falling back to the legacy 2.5 API - which does work.
I am told that it is free to upgrade to 3.0 API. See this comment as well as comment above by @cracklincrotch
Closing this issue as behaves correctly.


Update frame-metadata package to new substrate repository

Substrate has moved the frame-metadata package to a new repository: https://github.com/paritytech/frame-metadata, breaking all cargo updates --precise.
We should move the dependency to the new repository. If we import it with the feature  v13, only few changes should be necessary. See my commit in https://github.com/Polkadex-Substrate/substrate-api-client/pull/8/commits/843936f2298f65697a4d06f6e957055bad814add

Linking issues:  #166, #162


BUG:Footer Section

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?

The footer is not well coded some text are very small and they are not aligning well. Kindly assign this issue to me under relevant tags
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

hey @Bhum-ika can you please assign me this I will fix this issue


Private channels PREVIEW

Where can I request to be part of the Private Preview for "-MembershipType" switch ?

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

ID: fd44b411-4b59-b90f-0b82-ad0a87652854
Version Independent ID: 2c52cc4e-47a1-be0d-8860-1011adf061fd
Content: New-TeamChannel (teams)
Content Source: teams/teams-ps/teams/New-TeamChannel.md
Service: teams-powershell
GitHub Login: @kenwith
Microsoft Alias: kenwith

@officedocsbot assign @yogkumgit


This is a test PR

This PR introduces bogus code, but is here as a draft for collaborating on improving the coverage comment, related to #189

Coverage ReportFileStmtsMissCoverMissingfunctions/example_completed   example_completed.py641970%33, 39–45, 48–51, 55–58, 65–70, 91–92functions/example_manager   example_manager.py441175%31–33, 49–55, 67–69   example_static.py40295%60–61functions/my_exampels   example.py20200%1–31functions/resources   resources.py26260%1–37TOTAL105573930%

Tests
Skipped
Failures
Errors
Time

109
2 :zzz:
1 :x:
0 :fire:
0.583s :stopwatch:

bar
foo

I don't have any other idea for my comment above. I believe we're good from my point of view. Any other change you'd like to make @kieferro ?

I don't have any other idea for my comment above. I believe we're good from my point of view. Any other change you'd like to make @kieferro ?

That looks pretty good. Much clearer and more informative. However, I still have two things:

Is coverage_comment/ in this case supposed to be understood as COVERAGE_PATH or do we want to combine files in one folder in every case? For the latter case: Which system do we use for that? For example, what do we do if there are relevant files on several different levels of the file tree?
I have the feeling that the distinction between coverage data and DiffCoverage data is not entirely clear in the data points on the files. I assume, for example, the missing lines only refer to the code added by the PR? Perhaps we could then make this a bit clearer or, for example, as before, show both the coverage of the whole file and coverage of the added lines.

Is coverage_comment/ in this case supposed to be understood as COVERAGE_PATH or do we want to combine files in one folder in every case? For the latter case: Which system do we use for that? For example, what do we do if there are relevant files on several different levels of the file tree?

What I had in mind was to iterate on all the files that appeared on the coverage report, group them by "full folder path" and then display all the files belonging in the same folder together. No nesting. So for example:

a/b/

c.py
d.py

a/b/e/

f.py

g/

h.py

I have the feeling that the distinction between coverage data and DiffCoverage data is not entirely clear in the data points on the files. I assume, for example, the missing lines only refer to the code added by the PR? Perhaps we could then make this a bit clearer or, for example, as before, show both the coverage of the whole file and coverage of the added lines.

Excellent point. I guess it would make sense to have the new coverage (or even the evolution in coverage) for each file, but also the diff coverage, and those are 2 different things.
Maybe instead of Stmts | Miss | Cover | Missing, we should have Previous file coverage rate | Current file coverage rate | Coverage rate of added lines | Lines missing coverage | Added lines missing coverage. (this would mean we'd need to store much more precise data in the json file)

"Lines missing coverage" will have to link to the branch and not the PR.
"Added lines missing coverage" can link to the PR diff

Is it too much ? I'm afraid it might be overwhelming.

If we have previous coverage

Coverage report

Coverage details

Coverage Details
This table shows all the files where coverage has changed

FilePrevious coverage rateCurrent coverage rateCoverage rate of added linesLines missing coverage(Lines added by this PR in bold)

coverage_comment/

  files.py
96%
65/6698% 📈
2/366%

66,
  74

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/files.py#L66
https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/files.py#L74

  main.py
64/6696%
65/6698% 📈
2/366%

65–66,
  79

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L65-L66
https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L79

Project Total105573999%
Added by PR121083%

This report was generated by python-coverage-comment-action

If we don't have previous coverage

Coverage report

Coverage details

Coverage Details
This table shows all the files where coverage has changed

FileCurrent coverage rateCoverage rate of added linesLines missing coverage(Lines added by this PR in bold)

coverage_comment/

  files.py
65/6698% 📈
2/366%

66,
  74

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/files.py#L66
https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/files.py#L74

  main.py
65/6698% 📈
2/366%

65–66,
  79

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L65-L66
https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L79

Project Total105573999%
Added by PR121083%

[!NOTE]
No coverage data of the default branch was found for comparison. A possible reason for this is that the coverage action has not yet run after a push event and the data is therefore not yet initialized.
This report was generated by python-coverage-comment-action

Note:
I don't know which of those is better:
96%
vs
65/6698%

group them by "full folder path" and then display all the files belonging in the same folder together. No nesting.

Yes , sounds good.

I also like the new proposal, but I found the old one a bit tidier and easier to understand at first glance and actually I don't think it needs that many changes to the structure. I would just add a delta for each value. In order to highlight this in colour, we would have to work with a relatively large number of badges, because Markdown unfortunately doesn't support this natively, but otherwise why not just modify the original idea a little bit (The numerical values don't make sense, but you get the idea):

Coverage report

Coverage details
FileStmtsMissCoverCover (new lines)Missing

coverage_comment/

  files.py

74

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/files.py#L74

  main.py

65–66,
  79

https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L65-L66
https://github.com/py-cov-action/python-coverage-comment-action/blob/4e3ee3a9d2131c2a1ad3e35ee7dbeee737a1f88f/coverage_comment/main.py#L79

Project Total

This report was generated by python-coverage-comment-action

Also, I'm not quite sure if it makes sense to link all the missing lines. I can imagine that there are projects that do not yet have much coverage, which means that the missing lines that are actually relevant for PR are lost in the mass of missing lines. That's why I wonder if we shouldn't just focus on those?

Also, I'm not quite sure if it makes sense to link all the missing lines

Just to make it clear: not all the missing lines, just the ones inside files where coverage has changed for the PR. Reasoning is that sometimes, coverage changed somewhere because of a change elsewhere. For example, you want to move a test, and delete it but forget to re-add it elsewhere, the tested code lost coverage but it's not part of the diff, it's still linked to the PR.
I like the idea of badges, I note that GitHub adapts the badge size to the available size, making some quite small:

(Not saying it's a problem we need to solve. We can be ok leaving it as-is)
There's always a small ambiguity when saying 88% (+10%) because it's not clear if 10% applies to 88% (so it was 80% before and we added 10% of 80% which is 8 percentage points leading to 88%) or to the underlying value (so it was 78% before). But it's not a big ambiguity, I think it can be ok it we choose to keep it.
In my example, I've removed the branch coverage rate because I'm not sure it's more useful than confusing. We're in the context of a PR, and "branch coverage" could be easily understood as a synonym for "PR coverage" though it's completely different.
We're not displaying the number of new line added/covered, is this by design ? We're only displaying the percentage.
I had added a header row to the table, do you think it's worth keeping ?

Not all the missing lines, just the ones inside files where coverage has changed for the PR. Reasoning is that sometimes, coverage changed somewhere because of a change elsewhere.

Good point, I hadn't thought about that but, of course, it makes a lot of sense to do it that way.

There's always a small ambiguity when saying 88% (+10%) because it's not clear if 10% applies to 88%

Yes, I have thought about that too. I also thought about whether it would make more sense to write (-0.21pp) (pp meaning percentage points), but I think that would lead to even more confusion. Maybe we can add a footnote or a little explanation.

In my example, I've removed the branch coverage rate because I'm not sure it's more useful than confusing. We're in the context of a PR, and "branch coverage" could be easily understood as a synonym for "PR coverage" though it's completely different.

Ah sorry, I had just accidentally copied those from the original example. I'm completely on board with removing those :+1:

We're not displaying the number of new line added/covered, is this by design ? We're only displaying the percentage.

I'm not quite sure what you mean. For example files.py had 64 statements before and now has two more so 66 and it had 2 not covered statements and now has 3 not covered statements. Are you referring to the difference between statements and lines or what other information would be necessary in your opinion?

I had added a header row to the table, do you think it's worth keeping ?

I'm not sure, it takes up quite a lot of space. Why don't we move the information from it to the area that is clicked to expand:
Coverage details (Information about all the files where coverage has changed)

I'm not quite sure what you mean. For example files.py had 64 statements before and now has two more so 66 and it had 2 not covered statements and now has 3 not covered statements. Are you referring to the difference between statements and lines or what other information would be necessary in your opinion?

Say files.py had 64 statements and now has 66, and has 50% of added lines covered. Without more information, you'd probably think you added 2 lines, one of which was covered. But maybe you actually rewrote the whole file and covered 33 lines. I think the number of added lines may be important and is not deduced just by seeing how many lines there were before and there are now because you don't know how many were deleted.
The list of lines missing coverage may help get a sense of this but it's only showing missing lines.

Ah okay, I see. I have edited my proposal and also added this information. I think that it also looks a bit more consistent now. Would you agree with the layout and styling then?

I think we're good!

I've changed a detail on the <details><summary>:

I am currently working on the PR and I feel that it would be useful to make the selection of files that appear in the table a little different than it is now.
For example, if you delete a test case for a file, then if we go by DiffCoverage as before, the coverage loss in that file would not be shown.
So I think we need a different condition. The best thing I  can think of would be to include all files where the number of statements, misses or both have changed. Because in all these files something has changed in the tested code or in its coverage. What do you think about that @ewjoachim?

Yes, "listing all files where coverage has changed" was my current understanding of what we wanted to do so I guess we're aligned ?
(That said, maybe we should limit to, say, 50 or 100 files. Like: we'd show the 100 files with the biggest difference in coverage, ordered by name)

Coverage report
 Click to see where and how coverage changed
FileStatementsMissingCoverageCoverage(new lines)Lines missing

  code.py
12-14, 22
  other.py

Project Total

This report was generated by python-coverage-comment-action

Without previous
Coverage report
 Click to see where and how coverage changed
FileStatementsMissingCoverageCoverage(new stmts)Lines missing

  codebase
  code.py
3, 7-12

Project Total

This report was generated by [python-coverage-comment-action](https://github.com/py-cov-action/python-coverage-comment-action)

Coverage report
 Click to see where and how coverage changed
FileStatementsMissingCoverageCoverage(new stmts)Lines missing

  codebase
  code.py
6-8

Project Total

This report was generated by python-coverage-comment-action

Closed by #211


Integrate OpenSwathDecoyGenerator into EasyPQP

Implement OpenSwathDecoyGenerator into EayPQP

Create a separate branch with implementation
See: https://github.com/Roestlab/easypqp/tree/feature/openswathdecoygenerator

Added unit tests for CLI tool

Se PR: https://github.com/grosenberger/easypqp/pull/99


Add deploy script for production promotion

Also slightly reorganized deployment folder to be a bit more consistent.

TODO: change go/osv-deploy to reflect new process


Fix fd_orphan() in ev_epollsig_linux

If a polling_island_merge() happens between close(fd->fd) and polling_island_lock(fd->po.pi), it will try to add/delete the already closed fd to/from the polling island, and cause an epoll_ctl bad file descriptor error as #11530 caught.
This PR removes the fd from the polling island before closing it. It should fix #11530.

[trickle] No significant performance differences

[microbenchmarks] Performance differences noted:
Benchmark                                           cpu_time    real_time
--------------------------------------------------  ----------  -----------
BM_HpackParserParseHeader<IndexedSingleStaticElem>  +6%         +6%

Known issues:
Basic Tests Windows: #11745

Add @dgq for owners approval.

I'm important. I trust @sreecha 's judgement.


Scoped packages = invalid

I can see an issue here that claims to add support for scoped packages.
However, notice that the examples of scoped packages read "invalid":

Every time I've checked it over the past couple of days https://registry.npmjs.org/-/package/%40cycle%2Fcore/dist-tags has returned valid output and the last few daily runs of the NPM tests have worked so I'm going to close this - I think it is now stable again.


Add Appveyor CI

Codecov Report

Merging #606 into develop will increase coverage by 3.42%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #606      +/-   ##
===========================================
+ Coverage     89.9%   93.32%   +3.42%
===========================================
  Files           60       46      -14
  Lines         3001     2517     -484
  Branches       577      508      -69
===========================================
- Hits          2698     2349     -349
+ Misses         222      106     -116
+ Partials        81       62      -19


Use cargo-semver-checks to make sure derive feature doesn't change API surface

Zerocopy comprises two crates: zerocopy and zerocopy-derive. Zerocopy has a disabled-by-default feature called derive. When it's enabled, zerocopy depends on zerocopy-derive and re-exports its derives so that users can just depend on zerocopy and don't have to also depend directly on zerocopy-derive.
Some of zerocopy's types implement the same traits that we provide derives for (currently, FromZeroes, FromBytes, AsBytes, and Unaligned). When the derive feature is enabled, we use the derives to derive implementations of those traits for our own types. When the derive feature is disabled, we implement those traits manually.
This creates a potential footgun: How do we know that the impls we emit when derive is enabled are identical to the impls that we emit when derive is disabled? Do they have the same bounds?
This issue tracks using the cargo-semver-checks crate to detect such mismatches for us. We already use cargo-semver-checks in CI:
https://github.com/google/zerocopy/blob/3bb9a54ff458e104f7eb24beda7f8fb09794e1a5/.github/workflows/ci.yml#L207-L227
Specifically, this issue tracks using cargo-semver-checks to make sure that:

The derive feature is semver backwards-compatible with the absence of the derive feature
The absence of the derive feature is semver backwards-compatible with the derive feature

Combined, these two conditions should have the effect of ensuring that the APIs with and without derive are equivalent.
This issue tracks the following concrete tasks:

[ ] Using the technique described in this comment, update ci.yml's cargo-semver-checks use to check that:

[ ] The crate with the derive feature is semver backwards-compatible with the crate without the derive feature
[ ] The crate without the derive feature is semver backwards-compatible with the crate with the derive feature. Note that this case is extra tricky! The derive feature re-exports the derives, which means that the APIs are expected to differ! Specifically, we expect that the crate without derive will fail to be backwards-compatible because it has "removed" these exports compared to the crate with derive. You will need to do one of the following:

Figure out how to tell cargo-semver-checks to expect this difference, and allow it
Decide that there's no way to support this in cargo-semver-checks, and leave a comment in ci.yml explaining why we don't currently support this check

[ ] Intentionally push two PRs which include this technique and which update zerocopy's source code to violate compatibility:

[ ] One which makes a change which makes derive semver-incompatible with no-derive
[ ] One which makes a change which makes no-derive semver-incompatible with derive

Can you assign me this issue?


undefined: nexus.HandlerErrorTypeDownstreamTimeout error

Expected Behavior
To not see this error message.
Actual Behavior
Getting the following error:
# go.temporal.io/sdk/internal

../../../go/pkg/mod/go.temporal.io/sdk@v1.29.1/internal/internal_nexus_task_handler.go:480:36: undefined: nexus.HandlerErrorTypeDownstreamTimeout

Steps to Reproduce the Problem
Specifications

Go Version: 1.23
Version: go.temporal.io/sdk v1.29.1
Platform: macOS 15.1 (24B83) / ubuntu github runner

Using v1.29.0 fixes this issue.

Looks like this was fixed with the 1.30.0 updated.

Yes, this was an unfortunate case where our latest Go SDK version could not our latest Go API version. This should no longer be the case and we will try to prevent this issue in the future.


[RFE] Configure the number of indexed files

How do I configure the number of indexed files? 10 is the default but I would like say 20.

This is not configurable on the current build, but it seems reasonable we can set in the option.

I introduced max_timestamps option to customize this value.


Policy ui IDE plugin

@kazvictor, any specific IDE in your mind? IntelliJ or Eclipse?

It should be implemented in an IDE agnostic way as much as possible. There should be initial support for either Intellij or Eclipse and support for both eventually.

Tracked internally by F81667


Updated test jsx after adding All feature in theme

Fixed #24 test running errors.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@c8d21a3). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #25   +/-   ##
=======================================
  Coverage        ?   96.00%
=======================================
  Files           ?        4
  Lines           ?       25
  Branches        ?        1
=======================================
  Hits            ?       24
  Misses          ?        1
  Partials        ?        0

Continue to review full report at Codecov.

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


[WIP] [DO NOT MERGE] Plug Parameters inside current Instrumentation (attempt #1)

Types of changes

[x] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

Checklist

[ ] The documentation is up-to-date with the changes I made.
[ ] I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
[ ] All tests passed, and additional code has been covered with new tests.

keeping before dropping when #391 is merged, since #391 may need some pieces of it


TRAEFIK_VPN_ALLOWED_IPS is being changed to "/24" instead of whatever value is entered in .env

I'm not sure if this is an issue that needs fixing or if I'm misunderstanding things.
The following line resets the value of TRAEFIK_VPN_ALLOWED_IPS from whatever you entered during make config to the value of the VPN subnet + "/24":
https://github.com/EnigmaCurry/d.rymcg.tech/blob/67c36e13f6a8d5e014ff7b3d8cace3680a599808/traefik/setup.sh#L820
I discovered this because I think I need to manually add an allowed IP in order for my Home Assistant to be accessed as a peer, but after I add the IP (e.g., TRAEFIK_VPN_ALLOWED_IPS=<IP_ADDRESS>/24,<IP_ADDRESS>/32), make install resets the value to TRAEFIK_VPN_ALLOWED_IPS=<IP_ADDRESS>/24.

I do think that line that blindly resets the variable could be a bug, especially if you had set it to something more restrictive.
However, unless you are using this VPN as a general internet privacy guard, I don't understand why you would want to route any IP address other than the VPN subnet. 192.168 sounds like a private IP address, and so if it needs to be exposed, it should be exposed through a Traefik route, and that Traefik instance should have a VPN IP address starting with 10.13.16.x.

This appears to be the only place that variable is set? where else does it set it when you do make config? Or did you mean you set it in the .env by hand?

I think this is the only place that d.ry sets TRAEFIK_VPN_ALLOWED_IPS. I had set it in the .env  by hand and it got reset by make install.

I am not going to fix the potential bug I mentioned earlier, instead I added a warning not to change the variable. See 96e5b53
(I could have removed TRAEFIK_VPN_ALLOWED_IPS from .env-dist and just hardcoded it in docker-compose.yaml as ${TRAEFIK_VPN_SUBNET}/24, however I decided to leave the option with a warning instead.)


include: drivers: uart: fix incorrect event name in brief

The use of UART_RX_DONE was incorrect/invalid (the event does not exist).
This corrects the reference to UART_RX_RDY.
Fixes #31207
Signed-off-by: Jennifer Williams<EMAIL_ADDRESS>

I submitted this through the online editor and it seems to have an issue with my email that way. I guess I need to use standard approach, will try again.

See https://github.com/zephyrproject-rtos/zephyr/pull/31897. Closing this one due to compliance check when using web editor.


Update Webpack Config to Match Create-React-App

Facebook has combined their Dev and Prod Webpack Config files into one... with lots of conditionals. I'm not really a fan of it as it makes the file much harder to read. But even worse would be to lose sync with them and end up missing new functionality.

Fin!


Joreime/cortana

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

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

@zhuridartem please review


Fedora - Add support for multiple backends to fedora

Originally from the https://github.com/Islandora-Devops/isle-buildkit/README.md

Add support for multiple backends to fedora (currently only file is being used)

This functionality to toggle between backends (file, mysql and postgres) already exists in isle-dc & within the isle-fcrepo image as a feature which should be ported to isle-buildkit.

Is Fedora configured to use Blazegraph?

I'm taking a look at this now as I'm trying to get s3 working.

We now support mysql and postgresql.  With Fedora 6 those are the only two options (other than the embedded h2 for testing purposes), so we're good to close this one.


Issue with cmp

Hi, I recently wanted to switch from CoC to the native lsp and I figured I would use your plugin since I really like the philosophy it proposes.
I'm having issues setting up the completion.
As far as I understood, I need a plugin like cmp-nvim-lsp for that, so I added it to the requirements
use {
	'junnplus/nvim-lsp-setup',
	requires = {
		'neovim/nvim-lspconfig',
		'williamboman/nvim-lsp-installer',
		'hrsh7th/cmp-nvim-lsp'
	},
	config = function () require 'plugins.nvim-lsp-setup' end
}

then I run :PackerSync and added the capabilities to the plugin setup
local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities = require 'cmp_nvim_lsp'.update_capabilities(capabilities)

require 'nvim-lsp-setup'.setup {
	capabilities = capabilities,
	servers = {
		clojure_lsp = {}
	}
}

Now every time I enter Insert mode I get the following error messages
Error detected while processing InsertEnter Autocommands for "*":
E5108: Error executing lua ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:165: Vim(echomsg):E114: Missing quote: "Error in packer_compiled: ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:110: Vim(lua): E5108: Error executing lua ...pack/packer/start/cmp-nvim-lsp/lua/cmp_nvim_lsp/init.lua:48: module 'cmp' not found:
stack traceback:
        [C]: in function 'cmd'
        ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:165: in function <...m/site/pack/packer/start/packer.nvim/packer/load.lua:161>
        [string ":lua"]:1: in main chunk
Error detected while processing InsertEnter Autocommands for "*":
E5108: Error executing lua ...pack/packer/start/cmp-nvim-lsp/lua/cmp_nvim_lsp/init.lua:48: module 'cmp' not found:
        no field package.preload['cmp']
        no file './cmp.lua'
        no file '/usr/share/luajit-2.1.0-beta3/cmp.lua'
        no file '/usr/local/share/lua/5.1/cmp.lua'
        no file '/usr/local/share/lua/5.1/cmp/init.lua'
        no file '/usr/share/lua/5.1/cmp.lua'
        no file '/usr/share/lua/5.1/cmp/init.lua'
        no file '/home/sicro/.cache/nvim/packer_hererocks/2.1.0-beta3/share/lua/5.1/cmp.lua'
        no file '/home/sicro/.cache/nvim/packer_hererocks/2.1.0-beta3/share/lua/5.1/cmp/init.lua'
        no file '/home/sicro/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/luarocks/rocks-5.1/cmp.lua'
        no file '/home/sicro/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/luarocks/rocks-5.1/cmp/init.lua'
        no file './cmp.so'
        no file '/usr/local/lib/lua/5.1/cmp.so'
        no file '/usr/lib64/lua/5.1/cmp.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file '/home/sicro/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/lua/5.1/cmp.so'
stack traceback:
        [C]: in  function 'require'
        ...pack/packer/start/cmp-nvim-lsp/lua/cmp_nvim_lsp/init.lua:48: in function '_on_insert_enter'
        [string ":lua"]:1: in main chunk

From :PackerStatus I can see that cmp-nvim-lsp is indeed installed on ~/.local/share/nvim/site/pack/packer/start/cmp-nvim-lsp. If I uninstall cmp-nvim-lsp the error stops showing up.
What am I doing wrong?

Should I install nvim-cmp too?

Right now I have this
	use {
		'junnplus/nvim-lsp-setup',
		requires = {
			'neovim/nvim-lspconfig',
			'williamboman/nvim-lsp-installer',
			'hrsh7th/nvim-cmp',
			'hrsh7th/cmp-nvim-lsp'
		},
		config = function () require 'plugins.nvim-lsp-setup' end
	}

local cmp = require 'cmp'

cmp.setup {
	window = {
		completion = cmp.config.window.bordered()
	},
	sources = cmp.config.sources({
		{ name = 'nvim_lsp' }
	}, {
			{ name = 'buffer' }
	})
}

require 'nvim-lsp-setup'.setup {
	servers = {
		clojure_lsp = {}
	}
}

but when I open any Clojure file I can't see any completion

It's fine for me. You need to check :LspInfo and :LspInstallInfo.

In a Clojure file, running :CmpStatus shows
# unknown source names
- nvim_lsp
- buffer

and :LspInfo yields
Language client log: /home/sicro/.cache/nvim/lsp.log
Detected filetype:   clojure

0 client(s) attached to this buffer:

Other clients that match the filetype: clojure

Config: clojure_lsp
 Refer to :h lspconfig-root-detection for help.
 filetypes:         clojure, edn
 root directory:    Not found. Searched for: root_pattern("project.clj", "deps.edn", "build.boot", "shadow-cljs.edn", ".git").
 cmd:               clojure-lsp
 cmd is executable: true (checked by nvim-lsp-installer)
 autostart:         true
 custom handlers:

Configured servers list: clojure_lsp

and on :LspInstallInfo, it appears that clojure_lsp is installed

See: Not found. Searched for: root_pattern("project.clj", "deps.edn", "build.boot", "shadow-cljs.edn", ".git").

Hey I tried it in a Leiningen project and it shows autocompletion now. Thanks!
Unfortunatly I tried bot
local cmp = require 'cmp'

cmp.setup {
	window = {
		completion = cmp.config.window.bordered()
	},
	mappings = cmp.mapping.preset.insert {
		['<Tab>'] = cmp.mapping.select_next_item()
	},
	sources = cmp.config.sources({
		{ name = 'nvim_lsp' }
	}, {
			{ name = 'buffer' }
	})
}

require 'nvim-lsp-setup'.setup {
	servers = {
		clojure_lsp = {}
	}
}

and
local cmp = require 'cmp'

cmp.setup {
	window = {
		completion = cmp.config.window.bordered()
	},
	sources = cmp.config.sources({
		{ name = 'nvim_lsp' }
	}, {
			{ name = 'buffer' }
	})
}

require 'nvim-lsp-setup'.setup {
	mappings = {
		['<Tab>'] = cmp.mapping.select_next_item()
	},
	servers = {
		clojure_lsp = {}
	}
}

but in both ways I can't select a suggestion from the pop-up window. Is there probably something I'm misconfiguring

Sorry for being such a pain, I'm trying my best to make native LSP work once and for all :smiling_face_with_tear:

but in both ways I can't select a suggestion from the pop-up window. Is there probably something I'm misconfiguring

You need using preset mapping, cmp.mapping.preset.insert on cmp.setup.
cmp.setup({
    mapping = cmp.mapping.preset.insert()
})


UX CanJS

From https://github.com/donejs/donejs/issues/713

This issue was moved to canjs/canjs#2769


GH-32240: [C#] Support decompression of IPC format buffers

Which issue does this PR close?
Closes https://github.com/apache/arrow/issues/32240 / https://issues.apache.org/jira/browse/ARROW-16921
What changes are included in this PR?
This PR implements decompression support for Arrow IPC format files and streams in the dotnet/C# library.
The main concern raised in the above Jira issue was that we don't want to add new NuGet package dependencies to support decompression formats that won't be needed by most users, so a default CompressionProvider implementation has been added that uses reflection to use the ZstdNet package for ZSTD decompression and K4os.Compression.LZ4.Streams and CommunityToolkit.HighPerformance for LZ4 Frame support if they are available. The netstandard1.3 target has decompression support disabled due to some reflection functionality being missing, and neither ZstdNet or K4os.Compression.LZ4.Streams support netstandard1.3.
The ArrowFileReader and ArrowStreamReader constructors accept an ICompressionProvider parameter to allow users to provide their own compression provider if they want to use different dependencies.
Alternatives to consider
An alternative approach that could be considered instead of reflection is to use these extra dependencies as build time dependencies but not make them dependencies of the NuGet package. I tested this out in https://github.com/adamreeve/arrow/commit/4544afde6fef12337c7b188cc497da0bc1bf829d and it seems to work reasonably well too but required bumping the version of System.Runtime.CompilerServices.Unsafe under the netstandard2.0 and netcoreapp3.1 targets. This reduces all the reflection boilerplate but seems pretty hacky as now Apache.Arrow.dll depends on these extra dlls and we rely on the dotnet runtime behaviour of not trying to load them until they're used. So I think the reflection approach is better.
Another alternative would be to move decompression support into a separate NuGet package (eg.  Apache.Arrow.Compression) that depends on Apache.Arrow and has an implementation of ICompressionProvider that users can pass in to the ArrowFileReader constructor, or maybe has a way to register itself with the Apache.Arrow package so it only needs to be configured once. That would seem cleaner to me but I'm not sure how much work it would be to set up a whole new package.
Are these changes tested?
Yes, new unit tests have been added. Test files have been created with a Python script that is included in the PR due to only decompression support being added and not compression support.
Are there any user-facing changes?
Yes, this implements a new feature but in a backwards compatible way.

Closes: #32240

FWIW, the Java implementation does take the approach of separating out the compression dependencies into a new package, with only the interface (and a no-op implementation) in the core package. You do have to know to pass the compression codec factory explicitly in that case, unfortunately.

Thanks @lidavidm, yes I think having a separate package would make sense for dotnet too, and maybe that can be added in a separate PR so for now I've stripped this back to remove the reflection based implementation and just have an implementation in the test project.
I've also renamed things to be a bit more consistent with the Java API, although I've kept the ICompressionCodec API more narrowly focused so it only deals with decompression of dotnet memory buffers and Arrow buffer creation is handled by the internal IBufferCreator implementation, whereas in the Java API this is part of the CompressionCodec interface.
One question I have is whether it makes sense for the public compression API (ICompressionCodec and ICompressionCodecFactory) to live in the Apache.Arrow.Ipc namespace, or whether this should be moved down to Apache.Arrow if there's a possibility it might be used outside of the IPC format?

Java also puts the compression interface in its IPC package. C++ treats it as a more general utility (since it's also used for Parquet, etc.). Strictly in terms of Arrow I think it's fine to be in Ipc.

I see a script to generate some .arrow files and then also those .arrow files checked in.  Did you mean to commit the generated arrow files?

I see a script to generate some .arrow files and then also those .arrow files checked in. Did you mean to commit the generated arrow files?

Yes, I didn't think we'd want to depend on being able to run Python with PyArrow for the dotnet tests to run, but wanted to keep the script there partly as documentation on what should be in the files and so that people could regenerate them if needed. Do you think there's a better way to handle this?

Yes, I didn't think we'd want to depend on being able to run Python with PyArrow for the dotnet tests to run

I agree it is nice not to need this.

Do you think there's a better way to handle this?

For a few small files I don't think it's something we need to worry about too much.  There is a separate repository however, https://github.com/apache/arrow-testing which stores various test binaries and is already included as a submodule in apache/arrow.  If you find you need to generate more files in the future you could consider storing them there.