text:
rkt: add command to list images in the store.

This adds a new command "rkt images" to display the images in the store.
The -fields option let the user provide a comma separated list of fields to display. Accepted values: "key", "appname", "importtime", "latest".
The -sort option permits to sort the output according to the provided comma separated list of fields. Accepted values: "appname", "importtime".
The ordering is ascending by default but can be configured with the -order=[asc|desc] option.
By default all the available fields ("key", "appname", "importtime", "latest") are displayed sorted by ascending "importtime".
If the image has a version label its written in the app name (with the ":$version" format).
In future additional options can be provided:

show all the labels
define displayed time format (for example human format like "3 days ago").
filter by field value.

Examples:
$ rkt images
KEY                                                                     APP NAME                               IMPORT TIME                             LATEST
sha512-fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df coreos.com/etcd:v2.0.5                 2015-03-01 16:18:38.951 +0100 CET       false
sha512-683438b100a48aead6c37e4f581105713763bb41c3f995ad58a2cc49eb744d68 test                                   2015-03-01 16:53:47.45 +0100 CET        false
sha512-8cf2956f26035ac7d34b78722b8a738fae74acfe29b18db0a92ed44bbcfd2958 coreos.com/rocket/stage1:0.0.1         2015-03-01 17:02:34.636 +0100 CET       false
sha512-d6bb5eb2c30cd12d305192c395f783d7039136a7484f2e07761323a39a0915b6 coreos.com/rocket/stage1:0.0.1         2015-03-10 12:03:26.57 +0100 CET        false

$ rkt images -sort="appname,importtime" -order=desc -fields="importtime,appname,latest"
IMPORT TIME                             APP NAME                              LATEST
2015-03-01 16:53:47.45 +0100 CET        test                                  false
2015-03-10 12:03:26.57 +0100 CET        coreos.com/rocket/stage1:0.0.1        false
2015-03-01 17:02:34.636 +0100 CET       coreos.com/rocket/stage1:0.0.1        false
2015-03-01 16:18:38.951 +0100 CET       coreos.com/etcd:v2.0.5                false

I am a bit concerned that the headings don't match the name of the fields. For example the heading is "IMPORT TIME" but the user has to type "importtime". How do we make this more discoverable?

@philips we can use the same name for the headings and the fields (IMPORTTIME or something else without spaces) and additionally accept them with any case. What do you think?

@philips I updated the PR using the same name for headers and fields (IMPORTTIME and APPNAME) and accepting fields with any case.
Additionally, as it looks very useful, if the image has a version labels its written.

@sgotti @philips Any updates on this feature?

@kelseyhightower @philips I rebased the patch. By now the command is "images", should it become something like "image list" (#649) and wait for subcommands (#632) (as for #603).

@sgotti In the interest of not blocking further I'm going to land this now. We may come back to revisit the exact command framework and invocation (via #632 #649) but let's get it out there so we can kick the tyres. Thanks!!

authors: jonboulle kelseyhightower philips sgotti


text:
update file java-classes.data

There is no information on where this list comes from. We need to get some sources and update the list.

@spartantri Hi Manuel! I see that you have committed many of the lines here. Can you help us update this file?

Hey @lifeforms ! During our retreat you mentioned having more java classes to add to the list. Would you mind take care of this list then?

This was covered in #3048.

source: gharchive/issue

repo: coreruleset/coreruleset

license_type: permissive

license_source: bigquery


text:
Adds support for Carthage

I found that while it is stated in the README that Popover supports Carthage, this is not the case. Carthage requires a shared scheme that expose a framework. Popover does not have this.
I chose to place another Popover.xcodeproj in the root directory as this is where Carthage first and foremost expects to find the project. If it doesn't, it will loook through each directory in an alphabetical order to find it and we don't want it to find the xcodeproj for the example first.

Thanks for your work!! :+1:

source: gharchive/pull-request

license: mit


text:
Opt in/out Frontend

Summary

This PR implements the frontend for the opt in/out modal. This includes two parts:

[x] Task 1: Add the Settings icon with the Menu with “Replace, Remove” and “Replace” menus in the Req Bar. The Settings icon should be gray, but blue when hovered over (these colors already exist in the code base)
[x] Task 2: Create the Replace and Remove modals

Test Plan

To test the functionality, I will

Hover over the gear icon to ensure that the gear changes colors
Click on the gear icon to ensure the modal opens
Click on the remove button to open the remove modal
Click on the replace button to op

Choose a class not in the user's current schedule and one that is

For a class that is selected, there are three cases:

The class is not in the schedule, we need to add it
The class is already in the schedule once, so we just close the modal
The class is in the schedule more than once, so we open a modal to resolve duplicates

Case with 0 of that class

Case with 2+ of that class

@andxu282 Can you change the base branch to user-choice?

I added documentation here! Let me know if it's clear enough now
https://docs.google.com/document/d/12boyLpgJP2aizFjNI99Pt6yP5p5IqhAMkC-qGwes1fw/edit?usp=sharing

repo: cornell-dti/course-plan

license: MIT

license_source: github-api


text:
Update sbt-tpolecat to 0.4.3

About this PR
📦 Updates io.github.davidgregory084:sbt-tpolecat from 0.4.1 to 0.4.3
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.davidgregory084", artifactId = "sbt-tpolecat" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.github.davidgregory084", artifactId = "sbt-tpolecat" }
}]

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

Superseded by #210.

repo: cornerman/sloth


text:
fix: Fixes Angle Tool measurements (#1241)

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Bug fix

What is the current behavior? (You can also link to an open issue here)

The angle measurement is correct

What is the new behavior (if this is a feature change)?

The angle measurement was incorrect (fixes #1241)

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No.

Hey, this seems to fix the recently reported issues thanks!
Could you unstage the contributor changes?
We can add you as a contributor for your efforts, no problem, but we'll do this with the bot as its more reliable than manual changes.
Then very happy to merge, thanks for this.

unstage

Sure ! Done in 86bc26ed647474b3eef72edeca5cb3d96aa0e498

@all-contributors, please add @sbourouis for this great contribution!

authors: JamesAPetts sbourouis

repo: cornerstonejs/cornerstoneTools


text:
CWA does not recognize QR-Code of booster (i.e. 3rd) certificate, but the CovPass app does

[ ] Bug is not mentioned in the FAQ
[ ] Don't know whether Bug is specific for Android only
[ ] Bug is not already reported in another issue, I checked

Technical details

Samsung Tab A
Android version: 8.1.0
App version: 2.15.1

The bug
The CWA does not recognize the QR-Code on my last (3rd) COVID certificate, but the CovPass app does.
The CWA did not read the QR-codes on the 1st two certificates either but I was able to create files using a separate reader and then read those into the CWA. The same workaround was not successful with the 3rd COVID certificate as all readers I tried could not read that QR-code either, or rather, recognized only text

@6riah
Are you asking for help or did you just want to report a bug?
The next version of the Android app 2.16. is planned to use different scanning software. See https://github.com/corona-warn-app/cwa-app-android/pull/4590. That may help you when it is released.
Officially tablets are not supported by CWA (see https://www.coronawarn.app/en/faq/#smartwatch), however I checked on my own Samsung Galaxy Tab A (SM-T510) running Android 11 and CWA Android 2.15.1 and I was able to successfully scan a booster certificate.
Just for reference the scan FAQ is https://www.coronawarn.app/en/faq/#scan_tips.

This is correct, the scanning on Android will be significant improved with 2.16, the release is planned in ~10days

Internal Tracking ID: EXPOSUREAPP-8028
Internal Tracking ID: EXPOSUREAPP-10502

Can confirm that with Rev 2.16 I was able to scan the booster QR-Code no problem

@6riah Thanks for your feedback!
Best wishes, DS

Corona-Warn-App Open Source Team

repo: corona-warn-app/cwa-app-android


text:
Colors for risk status are hard to see for people with color blindness

Current Implementation
Currently when the user opens the overview page and scrolls to the paragraph that lists the possible risk status every status has a colored cirle beside them. The colors are red, green and gray. This can be hard for color blinded people to differenciate. One member in my family pointed out that he has a hard time to differenciate between the gray and green color.
Suggested Enhancement
I can think about two ways to tackle this issue:

The circles can be converted to different shapes to present diffrent risk statues.
They can be a settings that when turned on changes the colors to more friendly colors for color blinded people

Expected Benefits
The app should be usable for a large number of people. Making the app more open for people with a color blindness could help with that. Approximately 9% of mens and 0.8% woman have a kind of red-green color blindness.

This issue is related to both https://github.com/corona-warn-app/cwa-documentation/issues/170 and https://github.com/corona-warn-app/cwa-documentation/issues/191. The latter one's discussion also touched upon icons for different stati.

in my humble professional position: An app that is not well usable by close to 10% of the population is buggy. design for color blind people is not an enhancement, but a bug.

in my humble professional position: An app that is not well usable by close to 10% of the population is buggy. design for color blind people is not an enhancement, but a bug.

Not to mention that this is not just any app but an app that is supposed to be a tool to help contain one of the worst pandemics in recent human history.

I'll move this to the documentation repository (as it affects both apps) and we'll discuss again with the UX/UI designers. Contrary to corona-warn-app/cwa-documentation#191 the list of available statuses was not topic of an issue before

authors: Gregyyy h1-yena ilippert ironjan tkowark


text:
Rapid Test Profile - ä, ü, ö & ß are not correctly shown after QR-Code scan

Avoid duplicates

[X] Bug is not mentioned in the FAQ
[x] Bug is specific for iOS only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository - Can't check
[X] Bug is not already reported in another issue

Technical details

Device name: iPhone 6s
iOS version: 14.6
App version: 2.2.1

Describe the bug
The characters ä, ü, ö and ß are not shown to the user correctly.
Example

QR-Code
Data shown in CWA
Actual Result

Steps to reproduce the issue

Open the Corona-Warn-App
Scroll down to the "Register your Test" box & click on "Next Steps
Click on "Create Rapid Test Profile"
Enter the data, include one (or more) of the characters mentioned above
Once you have entered all data Click on "Save"
Scan the QR-Code with the native iOS camera app
See that the characters are not shown correctly.

Expected behaviour
The data shown & entered in the CWA should be the data that is stored into the QR-Code.
Additional information
Please check if this is a problem under Android too.

Internal Tracking ID: EXPOSUREAPP-7282

We have received more reports for Android in the stores as well, so it's confirmed the issue exists for both OSs. Therefore, I've moved the issue to cwa-documentation.

Corona-Warn-App Open Source Team

authors: Ein-Tim heinezen

repo: corona-warn-app/cwa-documentation


text:
Document public key used to sign exposure file in production system

It seems that currently the public key used to sign the exposure file/diagnosis keys that the CWA app receives from the backend server isn't documented anywhere.
Having this key publicly available would help enabling the signature verification in the microG exposure notification framework, see https://github.com/microg/GmsCore/issues/1307 for background discussion.

Internal Tracking ID: EXPOSUREAPP-10469

@Bubu Thanks for your request. Internal Tracking ID: EXPOSUREAPP-10469

@Bubu This is the public key:
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEc7DEstcUIRcyk35OYDJ95/hTg3UVhsaDXKT0zK7NhHPXoyzipEnOp3GyNXDVpaPi3cAfQmxeuFMZAIX2+6A5Xg==

We'll need to check where we could put it in this repo.

@Bubu
In the past, signature verification by Google's ENS could take an incredibly high amount of time for unknown reasons for older/low-end phones. On my LG-G4 it took around 70s in one test (derived from syslog some months ago). I'd suggest to do some performance checks when you enable it for microG. If microG has no problems at all to speedy verify signatures, then I'd suggest to have a look into Google's code (if possible) and file a bug report to them.
Unfortunately, since Google deactivated syslog for ENS in Europe due to data privacy reasons (elsewhere it's still active 😠 ), it's not possible to benchmark Google's signature verification currently.

@vaubaehn I just did a very minimal test with the public key from above added to the microG lib and verification was still very fast. I'm not too concerned about debugging googles implementation here though, I'll leave that to others :-).

@Bubu Thanks for the feedback. Happy to hear it's working good. So, If I got it right, ENS is actively downloading the public key everytime for signature verification? Then here's probably the bottleneck that I experienced... Good you can hard code the keys into microG.

I'm not too concerned about debugging googles implementation here though, I'll leave that to others :-).

True 😋

@vaubaehn

If I got it right, ENS is actively downloading the public key everytime for signature verification?

No, as far as I understand, apps have to provide their public key to Google/Apple when they request access to the ENF. At least that's what I gleamed from the respective documentations (Google), so I guess they keep an offline list of them somewhere in the ENF.
The comparing of the downloaded Diagonsis Keys (of people who are exposed) with the RPI collected by your phone gets more demanding as more people get sick, since your phone calculates all RPIs for all people who are sick (since it does not know anything about location, so if someone in Berlin gets sick and you live in Wuppertal you will still calculate his RPIs). I am guessing thats quite a lot to handle for older phones maybe?
But I never actually benchmarked any of this.

authors: Bubu awaigand dsarkar mlenkeit vaubaehn


text:
🛑 FashionLady.ro is down

In 93195ca, FashionLady.ro (https://fashionlady.ro) was down:

HTTP code: 403
Response time: 869 ms

Resolved: FashionLady.ro is back up in 54fa5e1 after 25 minutes.


text:
Lost with several CSS files

Hi,
I use lost in several CSS files (using Gulp). In this context, the following code is written in each file:
.container {
  max-width: 1000px;
  margin-right: auto;
  margin-left: auto;
  padding-left: 0;
  padding-right: 0;
}
.row {
  *zoom: 1;
  margin-left: -15px;
  margin-right: -15px;
}
.row:before,
.row:after {
  content: '';
  display: table;
}
.row:after {
  clear: both;
}
.container {
  max-width: 1000px;
  margin-right: auto;
  margin-left: auto;
  padding-left: 0;
  padding-right: 0;
}
.row {
  *zoom: 1;
  margin-left: -15px;
  margin-right: -15px;
}
.row:before,
.row:after {
  content: '';
  display: table;
}
.row:after {
  clear: both;
}

Would it be possible to have an option to write or not this part of the code (or another solution...)? In order to write only this code in one file.
Thanks

It would be an easy change, but I'm curious if it's the right move. Out of curiosity, why are you loading Lost into several stylesheets vs. 1?

TBH, I've never encountered this problem (even on pretty large projects).
I think you should be compiling a single stylesheet and @importing everything from there.
Closing this as I don't think we should add an extra setting to support bad practices. Will reopen if there's a good reason to load libraries several times throughout the same site or if more people seem to have this issue.

authors: corysimmons lionel-m

repo: corysimmons/lost


text:
initialSize can't be set to a value < 0.25

In InteractiveBottomSheetOptions, initialSize can't be set to a value < 0.25
assert(minChildSize <= initialChildSize) - This assert fails in draggable_scrollable_sheet.dart.

Fixed in Add minimumSize.

authors: ashilkn tombrell


text:
Vulnerability in axios< 0.21.1

Source: https://www.npmjs.com/advisories/1594
Overview
The axios NPM package before 0.21.1 contains a Server-Side Request Forgery (SSRF) vulnerability where an attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address.
Remediation
Upgrade to 0.21.1 or later.

Thanks @debaraj-barua, this is done.

authors: debaraj-barua tonyspiro

repo: cosmicjs/cosmicjs-node


text:
feat(stables): Add 2 stablecoins to Migaloo; axlUSDC and USDX

I tried to reuse links from other chains such as USDX's image to save on the duplication of the file

Please don't add those submodules

Closing due to staleness

repo: cosmos/chain-registry


text:
Update chain.json

Change validator alias

Please use an appropriate title for your PR

authors: alibabaedge reversesigh


text:
chore: adding Dockerfile and updating Release Workflow

Description

Adds the simd Dockerfile and updates the Release workflow to build and push the image on the v1.3.x release branch
part of #1908

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

@colin-axner if we are no longer doing releases from this branch then I think we can close this PR. And maybe archive it as you said!

@chatton that sounds good to me :+1:

authors: chatton colin-axner

repo: cosmos/ibc-go


text:
Fix the misusage of short-circuit evaluation in 'soter_sign_ecdsa.c'

I'm henry wong, from Qihoo360 CodeSafe Team. We found a possible null
pointer deference caused by the misusage of short-circuit evaluation. If
pkey is null, the program will continue execute EVP_PKEY_base_id(pkey),
and this will cause a null pointer dereference.
Since I'm unfamiliar with themis,  please forgive me if there is anything
wrong with my description.
Henry Wong
Qihoo360 CodeSafe Team

Thank you! Very good catch.
We found similar line in boringssl wrapper
https://github.com/cossacklabs/themis/blob/master/src/soter/boringssl/soter_sign_ecdsa.c#L93
We plan to fix both places and to add some tests.
Please, change target branch to
https://github.com/cossacklabs/themis/tree/soter_pk_fixes
We will merge your changes into soter_pk_fixes, and add few new checks.

authors: movie-travel-code vixentael

repo: cossacklabs/themis


text:
🛑 Mainnet Smartpy (mainnet.smartpy.io) is down

In 3466111, Mainnet Smartpy (mainnet.smartpy.io) (https://mainnet.smartpy.io/chains/main/blocks/head/header) was down:

HTTP code: 503
Response time: 15316 ms

Resolved: Mainnet Smartpy (mainnet.smartpy.io) is back up in 261ed99.

repo: cotezos/teznodes


text:
🛑 Mainnet [Marigold] (mainnet.tezos.marigold.dev) is down

In d99213e, Mainnet [Marigold] (mainnet.tezos.marigold.dev) (https://mainnet.tezos.marigold.dev/chains/main/blocks/head/header) was down:

HTTP code: 503
Response time: 445 ms

Resolved: Mainnet [Marigold] (mainnet.tezos.marigold.dev) is back up in f8d631f.


text:
🛑 Mainnet Smartpy (mainnet.smartpy.io) is down

In 65b8c60, Mainnet Smartpy (mainnet.smartpy.io) (https://mainnet.smartpy.io/chains/main/blocks/head/header) was down:

HTTP code: 500
Response time: 599 ms

Resolved: Mainnet Smartpy (mainnet.smartpy.io) is back up in cbe39f0 after 15 minutes.


text:
🛑 Mainnet Giganode is down

In 268f4b5, Mainnet Giganode (https://mainnet-tezos.giganode.io/chains/main/blocks/head) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mainnet Giganode is back up in 20e180a.


text:
🛑 Umami API ghostnet is down

In 789cf1a, Umami API ghostnet (https://ghostnet.umamiwallet.com/monitor/blocks) was down:

HTTP code: 404
Response time: 479 ms

Resolved: Umami API ghostnet is back up in 1c2c0c4.

repo: cotezos/umami-api-endpoints


text:
Fixes to get cross compilation working with c++20

The majority of the time spent on this was in order to get proper toolchains and sysroots.  They still may not be proper but they work....

Superseded by #573

repo: couchbase/couchbase-lite-C


text:
"Delete error","Update conflict" also happens in DB015

Originally filed: https://github.com/couchbaselabs/mobile-training-todo/issues/155
in this project depended DB015, when one item is deleted, the error is "com.couchbase.todo
E/LiteCore [Sync]: {3} Got error response to rev user1.b2fc4cf0-9a70-4243-b8b4-4bbda1ff4654 #2-98d2b4aa00f91b56212ce489855c7a734e9a9d31 (seq 6): HTTP 500 'Internal error: EOF'". when two client devices update the same item,the error is "8-30 12:00:12.836 29117-29117/com.couchbase.todo E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.couchbase.todo, PID: 29117
java.lang.NullPointerException
at com.couchbase.lite.ReadOnlyDocument.setC4Doc(ReadOnlyDocument.java:104)
at com.couchbase.lite.ReadOnlyDocument.selectConflictingRevision(ReadOnlyDocument.java:187)
at com.couchbase.lite.Database.resolveConflictInDocument(Database.java:643)
at com.couchbase.lite.Replicator.documentError(Replicator.java:427)
at com.couchbase.lite.Replicator.access$100(Replicator.java:35)
at com.couchbase.lite.Replicator$1$2.run(Replicator.java:397)
at android.os.Handler.handleCallback(Handler.java:808)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:5292)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:824)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:640)
at dalvik.system.NativeStart.main(Native Method)"。

Hi @loongsun,
I can not reproduce the problem with ToDo sample.
Can you provide steps to reproduce the problem?
Thanks!

emailed to you with steps vedio already!

Hi @loongsun,
I did not receive the email. Can you resend it to me? Thanks!

This ticket could be duplicated with #1242

With LiteCore module's fix, this issue is fixed.

authors: djpongh hideki loongsun

repo: couchbase/couchbase-lite-android


text:
Fixed https://github.com/couchbase/couchbase-lite-android/issues/898

Push replication failing with large data sets

Solution: Implement pause logic into PusherInternal. In case total count of Batcher and pendingSequences sizes are more than 200, push replicator pauses to add changes into Batcher. This is same approach with PullerInternal pause logic.

@pasin, Could you please review again?
Changes

make beginReplicating() not call from ExecutorService to avoid potential problem
Instead, make minimum thread-pool size of remote request executor to 2

We should create a ticket to rethink about the replicator work executor and the way that waits for pending future and etc.

authors: hideki pasin

repo: couchbase/couchbase-lite-java-core


text:
Use a Standard-Compliant License Identifier

This pull request changes the value of the license property in package.json to a standard, machine-readable SPDX license identifier.
I'll be honest: This is a semi-automated pull request. I started by using dat and dat-npm to review metadata for all packages on npm, looking for packages that don't use a valid SPDX license identifier in package.json. I used my own npm module, spdx-correct to guess what license you were after: "Apache-2.0". A quick manual check and a few shell scripts later, and this pull request was born.
npm doesn't require that you use a valid SPDX identifier, but it's strongly recommended. (Try npm help 7 package.json and search for “License”.) Other source code package managers, like Maven for Java and RubyGems for Ruby, recommend the same.
Why care about SPDX? A machine-readable standard makes it possible for programs, rather than just people, to review a module or even an entire codebase to make sure that licenses are compatible. Whatever the reason—strong personal conviction, company policy, terms of a business deal—SPDX makes it easier to collaborate with others when licenses can be a problem, and helps take open-source software to more places. Given that npm has a ton of modules but also handles dependencies in a novel way, I think a little license hygiene could help npm build amazing new relationships between communities that lawyers have long kept apart.
Though this PR was semi-automated, my responses to any questions you have won't be. I can't give legal advice via GitHub, but I'm happy to answer questions about SPDX or point you to good resources.
Thanks for your contribution to open-source software!
K

Thanks, Brett!

repo: couchbase/couchnode


text:
Meta data purge in couchbase

I am using couchbase 4.1. when i delete the document, a new revision of document is getting created with attribute deleted=True. when compaction runs older revisions are getting deleted but am curious to know when the latest document (which is having only meta data) is going to delete from couchbase permanently. same i have posted in forum . but no luck.
Is there any setting i am missing ?. also wanted to know will it delete from replica too.

In traditional "couch" this latest document meta-data with deleted=True remains forever.  It is sometimes referred to as a tombstone because "couch" needs to know about deleted documents that once existed for replication processes like XDCR to give correct behavior.
I keep saying "couch" because this is an area of technology that came from CouchDB but has changed through the history of Couchbase Server.  In Couchbase Server there is now a process called Tombstone purging or Meta-data purging.
I found a page in the docs about it here:
http://docs.couchbase.com/admin/admin/Concepts/concept-tombstone.html
That page is from the docs for 3.x, I don't see mention of it in newer releases, so I'm not 100% certain if/how its changed since then.

I am running 4.0.I had set meta data purge interval=0.04. but i done see tombstones deleted even after 15 days.

I would recommend you open a bug on the Couchbase Server issue tracker.  It will be the most direct way to get a response from people knowledgable about the issue: https://issues.couchbase.com

mschoch, looks like i done have access to create jira issue.

Can you provide more information?  You will need to create an account to file an issue, but there should not be restrictions preventing you from doing so.

Actually I just learned that our JIRA accounts require an admin request.  If you don't mind, please submit one and I can try to make sure it gets processed in a timely manner.

@mschoch , I have submitted one but the screen just disappears after submitting without any response.
"Tombstones deletion" subject i have used.

When you say "I have submitted one" you mean you filled out the administrative request form?  If so I'll try to follow up today.  When did you submit it?

yes i have filled and sent request to Jira administrator.

any luck on this @mschoch .

I am following up with them now, sorry for the delay.

Very sorry for the JIRA trouble @ArihantRk.  While it's not my area, I've just now fixed your account and reset your password.  You should receive an email to complete the reset.
Long story short, there is an SSO project that is a bit stuck at Couchbase.  I'm going to follow up with the responsible folks to make sure they're aware of the problems it's causing.
If the fix/reset doesn't come through, please let me know.  My first name at couchbase will get a message to me.  ;)

Thanks a lot matt, I am able to create ticket. is has been created ,
https://issues.couchbase.com/browse/MB-19163

authors: ArihantRk ingenthr mschoch

repo: couchbaselabs/couchstore


text:
Access denied when trying to download 2.2.1 plugin

I am trying to download package from link which you described in readme
http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.2.1/elasticsearch-transport-couchbase-2.2.1.zip
But get access denied

Same here, 403 I can't install anymore the plugin

Sorry, readme was updated prematurely. Fixed the install instructions now.

This appears to be an issue again, the link below gives me a 403 error.
bin/plugin -i transport-couchbase -url http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.2/elasticsearch-transport-couchbase-2.1.2.zip
Thanks,
Jonathan

authors: Branor Puzochacha jcspino veacks


text:
(cmos-23): Add CMOS configuration docs

Signed-off-by: Chandan Kumar chandan.kr404@gmail.com
Add docs for CMOS-23

@roshanisanghavi @maria-robobug appreciate final review and merging

Addressed the review/comments

repo: couchbaselabs/observability


text:
add MergeBuilder

The MergeBuilder would take n FST instances and a Writer as input, and produce a new FST containing the merged contents.  Implementation just has to create iterators on the underlying FSTs, walk them, and insert to the new one in order.

I really like this idea.
Would there be a shortcut function, perhaps called something like Add[Slowly]() to "merge" a single record?

I really like this idea.
Would there be a shortcut function, perhaps called something like Add[Slowly](), to "merge" in a single record to an existing FST?

Going to give it a try

I'm actually working on a merging iterator right now, which would be one of the pieces needed.

Yeah, I kept looking into merging one into another but that did not work, so the only solution was to iterate through both and insert into a new one. And it can be done in O(n+m), where n is length of the first and M being the length of the second. If we can iterate in a sorted order! WDYT?

Yes, iterating both and building a new one is what I expected.
The piece I'm working on right now does 2 things:

make Iterator an interface (not strictly required for this phase, but enables a few other things later)

new MergingIterator which takes a slice of []Iterator

The purpose of this is to iterate all the underlying iterators and emit the union of the N iterators passed in.
Additionally, there is user callback to decide how to merge values when the same key is in multiple iterators.
Then, a merging builder of N FSTs just has to get an iterator for each, pass it into the MergingIterator, and then walk it, passing emitted key/value pairs to the new builder.

authors: jaytaylor mschoch seiflotfy

repo: couchbaselabs/vellum


text:
use sqlite3 for local data

makes the most sense for htlcstreamer also useful for .history.pkl

Here is an example of how you can store a dictionary in an SQLite database using Python:
import sqlite3

# Create a connection to the SQLite database
conn = sqlite3.connect('database.db')

# Create a table to store the dictionary
conn.execute("CREATE TABLE dictionary (key text, value text)")

# Define the dictionary
my_dict = {
    'apple': 'red',
    'banana': 'yellow',
    'orange': 'orange'
}

# Insert the key-value pairs into the table
conn.executemany("INSERT INTO dictionary VALUES (?, ?)", my_dict.items())

# Save the changes to the database
conn.commit()

# Close the connection to the database
conn.close()

to get the data back
# Use a SELECT statement to retrieve the key-value pairs from the table
cursor = conn.execute("SELECT * FROM dictionary")

# Retrieve the rows from the table
rows = cursor.fetchall()

# Convert the rows into a dictionary
my_dict = dict(rows)

repo: count-null/rain


text:
#cvn-mediawiki

Please create a CVN channel for mediawiki using a bot. Thanks!

:white_check_mark: done (#cvn-mediawiki)

authors: eurodyne rxywm

repo: countervandalism/CVNBot


text:
Update final paper output

This issue focusses on only showing the output in the final paper output and fixes knitting issues by adding the right libraries and code.
Kind regards,
Julian Peters

Pushed directly with team members checking.


text:
Pipe Dream: Coursier "Solve"

What follows is part brain-dump, part RFC, and part "somebody please do this because dear god I need it but I don't have enough time". Happy for this to exist somewhere else if the maintainers prefer, but I thought it made sense here.
Problem
You depend on a set of libraries. Let's say the following:

Http4s
Redis4Cats
Monix Catnap
Ciris
Pick any two of the fifty things in the Davenportverse
Fs2

(to be clear, these are your direct, stated dependencies in your build.sbt)
You want to upgrade any one of these. For example, assume http4s. However, upgrading one results in the other now depending on an old version of something transitive. Maybe catnap is now broken because http4s pulls in a newer version of Cats Effect, or conversely maybe there's a better version of Cats Effect that can be grabbed and explicitly evicted to. Upgrading http4s potentially messes up downstream things, such as almost anything in the Davenportverse, so that's a concern.
It's very complicated and hard, and ultimately requires a relatively expert-level knowledge of the ecosystem and its transitive dependencies (and who happens to be maintaining bincompat and who isn't!) in order to figure it all out. It's also very time consuming to do by hand.
To be clear, this problem generalizes to any polyrepo distribution system. Companies which use polyrepos actually feel this problem far more acutely than the public ecosystem (believe me…). This, in a nutshell, represents the strongest objective argument against an extensible ecosystem: it's incredibly difficult to identify "compatible sets".
Possible Solution
What if we could just… ask Coursier? Think about something like this (literally making up syntax here):
$ coursier solve --scala 2.13 org.http4s::http4s-server org.typelevel::cats-effect:2.2.0 dev.profunktor::redis4cats-effects 'co.fs2::fs2-io:2.[3,)'

Imagine if Coursier then would spit out the most recent, maximally-compatible set of dependencies, ideally in a way that can be copy/pasted into a libraryDependencies declaration. The idea here is that we're expressing a set of constraints (note the missing versions). We want these things, some of which with this specific version, some with an Ivy range, and some without any version at all, and we want the solver to figure out what our ideal build configuration should be in order to ensure everything is mutually compatible but also upgraded as far as possible.
Additionally, note the Scala version is explicitly included here. This is partially for convenience (so we can use the fictional :: notation), but also so that Coursier can find versions which comply with our version. Not everyone is on the latest Scala, and sorting out compatible sets on older versions while upgrading as much as possible is a massively non-trivial problem, particularly when libraries like Circe have conditional dependencies that jump between breaking lines and other non-linear things.
Obviously this isn't possible right now. But I think it could be.
Implementation
There are a couple things that would be needed for this. The most obvious one is some assumptions about declared compatibility in versioning. Coursier already defaults to Ivy's eviction rules on this one, and I think that's fair, but it should be overridable on a per-artifact basis. For example, Cats Effect is fully binary compatible within its major lines, and additionally happens to be binary compatible between 1.x and 2.x (Cats is as well), and it should be possible to declare this somewhere in a fashion that all users have access to it. Ideally this would just be in the POMs, but we can't necessarily do that, so some external metadata mechanism is probably necessary. This wouldn't need to be in MVP, but it would be helpful.
The biggest piece though is the solver itself. From what I remember from the last time I looked into this, Coursier's resolver is almost powerful enough to do this, save for one critical piece: it doesn't support backtracking. Coursier's resolver isn't a general constraint solver, it's just a straightforward iteration algorithm that attempts to resolve conflicts by evicting forward. This is entirely sufficient to replace Ivy in sbt, but it's not enough to achieve this idea.
However, I don't think it would be hard to make it enough. Constraint solvers honestly aren't that hard to write (stick your constraints into a set, then iterate on that set until you either instantiate every variable or you complete an iteration without making any changes), and implementing this would greatly extend Coursier's capabilities and allow it to fill this critical and glaring need within the ecosystem.

Do all these libraries implement strict Semantic Versioning?

I've actually started on a project which has a similar goal - a view of the ecosystem as a multi-graph, that can be traversed from a set of requirements. In my case the requirement was "is it ready for 2.13?" which is reflected in the labeling (green/red).
The original idea was to guide people who want to contribute to Scala version upgrades in the ecosystem that are desperately needed, but this has similar problems - the quality of the raw data that can be sourced from, say, Scaladex, is not good enough to solve for "Pick a subgraph that will be completely in 2.13 if you upgrade this minimal set of dependencies in this order"

Do all these libraries implement strict Semantic Versioning?

Many, not all. This should be configurable. We're always going to have weird issues like ScalaCheck (which breaks things in their minor line) or even Netty. My thought would be that this command would take, in the arguments, a list of artifact selectors paired with known resolution strategies, or alternatively an external manifest which contains the same (so that this can be shared). I touched on that in a highly imprecise way in the OP.

@keynmol First off, that is absolutely fascinating. But second, I think working within Coursier's infrastructure would probably have made your job a lot easier there. :-D Coursier's internal APIs are actually really good and really well-factored, so it's not difficult to recompose them to do other things. To be clear, the OP is barely even a recomposition of its internal APIs: it's just a minor addition to the resolver which is already architecturally-compatible with backtracking. But doing more elaborate things like what you're talking about should also be relatively straightforward.

To the point just above: one of the first responses to a slightly different proposal I made against pip (pypa/pip#7819) was (as in https://github.com/coursier/coursier/issues/1863#issuecomment-695828508) to make use of a new endpoint from the artifact host to fetch dependencies quickly, instead of adding more infrastructure in the resolver. I will note that regardless of that feedback, I worked on implementing it in the pip resolver itself (e.g. pypa/pip#8448). From that vaguely-relevant experience, I will say that I am somewhat convinced this can and should be done in the resolver tool itself.

@djspiewak the actual resolution for the graph is all done through Coursier :) because it's amazing. The seed data for "what are the core nodes we want to have in the infrastructure, for which precise dependency information is required" is sourced partially by hand partially from Scaladex.
Seeing this post I might just experiment with what the graph looks like with precise versions added back in, and what would jumping from one to another would look like in terms of subgraphs and number of updates.

Coursier already defaults to Ivy's eviction rules on this one, and I think that's fair, but it should be overridable on a per-artifact basis.

sbt 1.4.0 will add ThisBuild / versionScheme (https://github.com/sbt/sbt/issues/5710), and there's a plugin called sbt-version-policy that Alex wrote that lets you locally override similar information:
versionPolicyDependencyRules += "org.scala-lang" % "scala-compiler" % "strict"

The biggest piece though is the solver itself.

When we ask a module with a few libraryDependencies effectively it's doing the solving. What's NOT happening (and it should) is resolver saying "I'm sorry I can't" when the constraints are incompatible. So I think what we are asking is strict mode based on more accurate compatibility check based on Semantic Versioning, PVP, etc declared by the library.

What's NOT happening (and it should) is resolver saying "I'm sorry I can't" when the constraints are incompatible. So I think what we are asking is strict mode based on more accurate compatibility check based on Semantic Versioning, PVP, etc declared by the library.

In part, yes. But the current "solver" also doesn't backtrack. For example, when trying to find a compatible set between dependencies A and B, there is no current functionality which can look at the transitive dependencies of A and B and find compatibility there, then backtrack up to A and B themselves and see what can be compatible with those upstream modules. This is far and away the most painful bit today, and the current tooling cannot achieve it.

ok.
If we use  org.http4s::http4s-server as an example, assuming none of org.typelevel::cats-effect:2.2.0 dev.profunktor::redis4cats-effects 'co.fs2::fs2-io:2.[3,)' depend on http4s-server, you're asking Coursier to go from the latest and try different http4s-server versions to find the maximum version of http4s-server that fits the puzzle.

you're asking Coursier to go from the latest and try different http4s-server versions to find the maximum version of http4s-server that fits the puzzle

Yes. Abstractly, the goal is to spit out a set of concrete versions for all the artifacts listed in the arguments, where the versions are all mutually compatible not just in direct dependencies, but also throughout their transitive diamonds, and where any version ranges (or version omissions) are resolved to the most recent possible options.

Additionally, if some versions are strictly in mutual conflict (like if I ask for an fs2 version that depends on a cats version which is strictly incompatible with a cats version that I also specified), then we should get an appropriate error.

where the versions are all mutually compatible not just in direct dependencies, but also throughout their transitive diamonds

Question on this part. This seems like a strictly more difficult problem than might exist within an actual repo. I'm assuming the goal is to allow a single coursier invocation to provide all these compatible sets of artifacts so e.g. sbt can then assign one (or more) of those compatible sets to each subproject (not sure of the precise nomenclature -- a subproject meaning "a thing that specifies a set of artifacts to resolve, which its source files can then freely import, if the resolve is satisfied". pants calls it a "target").
However, these mutual compatibilities would not seem to be necessary if no subproject actually depends on any such incompatible combination. To attempt to be more clear about this, if I have A resolving artifacts a:1.0.0 and b:2.0.0, and B resolving artifact a:0.9.5, we would not need to calculate whether a:0.9.5 is compatible with b:2.0.0. Now, the current setup you've described would of course handle this case correctly, as it would have to partition into two compatible sets at the start just by having two separate versions of artifact a, which the build tool would process and easily map to the correct targets.
However, one suggestion I might make which mirrors the way I'm solving this for python dependencies at Twitter, is to specialize the input provided to the coursier solve operation, into a mapping of (target name) -> (set of artifact dependency constraints). This relies on the assumption that the build tool is able to provide a unique string (the target name) for each "subproject", as defined above (could also call it the subproject name -- would like to stick with nomenclature most people recognize obviously). This could be provided as JSON to coursier over stdin or a file argument. If provided this mapping, instead of being given a flattened set of dependencies without this context, and attempting to do the harder problem of finding compatible sets that will work assuming the subproject dependency graph is fully connected and acyclic, we could e.g. start by performing a resolve for all of the leaf subprojects (without any dependencies), then "merge" upwards into their parents (the subprojects they depend on). I have some thoughts on what such a "merge" operation would look like. The only assumption made here is that each subproject must have the exact same version of an artifact as all of its transitive dependencies. In a large monorepo, this obviously becomes a harder problem and would result in more partitionings. If I understand your usage of "polyrepo" correctly, it may be that each repo would correspond to what I'm referring to as a "subproject" here.

Am I understanding your statement of the coursier solve use case correctly, and is the reasoning that it may be solving a harder-than-necessary problem clear?
Is this (target name) -> (set of artifact dependency constraints) concept generic enough and simple enough to expect as input to coursier solve?

Thanks for reading, please let me know if this is unsuitable for the project for any reason.

Ok, given that I just realized the above is a totally different problem, I would like to ask a separate question, which is directly from the prompt: what would we want to do in coursier if instead of the slightly-vague "upgrade as much as possible", we wish to upgrade to a specific version of e.g. http4s, say because it made one function call super fast, and there's no path to doing that which doesn't cause an incompatibility? I assume that coursier solve would fail in this case, but what information would we provide in the error output?
Specifically, would it be useful to try to then solve for the minimum set (or smallest few) of upgrades to other artifacts necessary to accomplish the desired http4s upgrade?

I've re-read the prompt, and I think I completely misunderstood the idea. So the below would be a description of a proposal for something that's not at all solving the stated problem of defining a set of constraints with maximum compatibility to ease further upgrades, which would be useful for publishing individual libraries that break things less often

I'll read your comment a little more thoroughly in a second, but just to quickly clarify before my next meeting… The idea is targeted at consumers of libraries, not publishers. And while it does provide additional benefits in polyrepo setups, is certainly is not exclusive to it, since the entire open source universe is (fundamentally) a polyrepo configuration, so even monorepos need to solve this problem when sorting out their dependencies.
Simply put: the problem at hand is finding the correct set of versions of various libraries to marry together in your own build.sbt, subject to some other constraints (Scala version, pinned versions of certain libraries, biasing towards most recent, etc). If you're using a polyrepo layout, then you need to solve this problem not just across open source libraries, but also across your organization. If using a monorepo, then you only need to solve it for external libraries (though your set of constraints will often be much, much larger as a consequence of your larger project surface area). Either way, it's a problem.

Ok, given that I just realized the above is a totally different problem, I would like to ask a separate question, which is directly from the prompt: what would we want to do in coursier if instead of the slightly-vague "upgrade as much as possible", we wish to upgrade to a specific version of e.g. http4s, say because it made one function call super fast, and there's no path to doing that which doesn't cause an incompatibility? I assume that coursier solve would fail in this case, but what information would we provide in the error output?

The OP kind of gets at this case a bit with the pinned versions. I gave an example of pinning Cats Effect to specifically 2.2.0 (realistically it probably should have been 2.2.+, but you get the idea). CE 2.2.0 introduced tracing, as well as a number of performance optimizations, so this is a plausible example.
The workflow would be something like this:

Team identifies a desire to adjust artifact A to a given version range (perhaps a specific version). Note that this may actually be a downgrade to avoid some sort of regression.
Person tasked with said upgrade puts the current dependencies (and their constraints, which may themselves be specific versions), including A and its desired version, into coursier solve
The solver says "unsolvable" and lists the conflicting constraints (this is relatively easy to determine algorithmically). For example, perhaps the pinned version of http4s depends on a version of fs2 which depends on Cats Effect 1.x
Team makes a decision about the conflicts, which results in either giving up on the upgrade, or changing one or more of the other artifact constraints
Repeat from step 2

From a tooling standpoint, this actually is remarkably close to how NPM works if you pin (and commit) resolutions (which almost no one does), though I think NPM's resolver is forward-only so it's strictly less general than this problem.
It certainly would be useful to be able to represent artifact version constraints in some sort of file which can be loaded by coursier solve and committed. The libraryDependencies contents would effectively be generated by running coursier solve (and obviously themselves committed). This would be a pretty slick workflow, particularly if tooling like Scala Steward could be made aware of it, but it simply represents a convenience layer on top of what is proposed in the OP. The bar is pretty low here. :-)

where the versions are all mutually compatible not just in direct dependencies, but also throughout their transitive diamonds

Question on this part. This seems like a strictly more difficult problem than might exist within an actual repo.

I think you worked your way around to the answer on this one, but just to clarify… :-)
Resolving transitive diamond conflicts is the hardest problem in this space right now. The example in OP doesn't demonstrate this simply because I included a version for Cats Effect, but if we omitted Cats Effect (which is an upstream dependency of several artifacts in that list), we would very quickly run into interesting problems. For example, we want a working version of Ciris and Http4s, and we want at least version 2.3.x of fs2, which in turn implies that we need at least a certain version of Cats Effect. What version is that? To answer that question right now (like, literally to compose that comment), I literally need to pull up the fs2 github repository and read the build included in the various tags.
Additionally, what version of http4s is compatible with this stuff? What if we had introduced a more complicated series of constraints by upper-bounding one of the dependencies? (not an uncommon situation) For example, if we only allow fs2 versions in the 2.3.x line, that probably means we can't use the latest http4s, so which version can we use? And in turn, what does that mean for other libraries? Imagine for example that we're using cormorant-http4s; what version of that are we allowed to use if http4s itself has been solved to be a particular version, ultimately due to bounding fs2-io? This is why the solver can't just be forward-only, as the current resolver is: it needs to backtrack up to http4s (or even cats effect, in my earlier example) using the bounds inferred via the declared fs2-io bounds, and then in turn work back up into cormorant-http4s, all while looking at Cats Effect and working back upwards to Ciris (though, since we know CE is using semver, that might be a more straightforward problem).
You see how this gets immensely complicated in a hurry. :-) At least to my mind, this is the biggest problem with having a large set of dependencies, even well-maintained ones. It gets even crazier if you're trying to solve this internally to your organization as well as externally. If you have a relatively prolific polyrepo ecosystem, which in turn intersects with the public ecosystem via transitive dependencies, it can be quite challenging to assemble compatible versions even for your own dependencies across teams.
Needless to say, I would expect coursier solve to accept custom repository configurations, just as the other commands do. :-)
At any rate, hopefully this clarifies the use-case a little further.

So if a dependency employs semver, are we just taking advantage of the understanding that we can take any two points in the totally-ordered set of versions for that dependency and represent that as a contiguous version range? That actually sounds like the description maven provides for non-semver versions, so I'm assuming that semver perhaps just reduces the complexity of the search (to not just "everything in lexicographic order")? Especially as those maven docs state "Maven does not consider any semantics implied by that specification", and I'm assuming that transfers to coursier?

In general, this whole thing is going to have to make assumptions about versioning. Specifically, for a given artifact that has two versions, v1 and v2, can we replace v1 with v2 without affecting the rest of the graph? The answer to that question dictates the solution space, and unfortunately it requires metadata that we simply do not have for general maven artifacts.
The best thing to do, IMO, is pessimistically assume epoch.major.minor versioning, which is relatively common (particularly int he Scala ecosystem), and allow people to declare major.minor.revision if relevant. In future, it might be possible to share this metadata (e.g. some common dependencies, such as Cats and Cats Effect, use semver). Another option if we want to be really computationally intensive would be to use mima internally to check revisions against each other, though that's going to slow down the solution process (as well as introduce an entirely new bit of functionality and infrastructure to Coursier).

Thank you for clarifying that point!

Another option if we want to be really computationally intensive would be to use mima internally to check revisions against each other, though that's going to slow down the solution process (as well as introduce an entirely new bit of functionality and infrastructure to Coursier).

My first thought is that I would assume this could be a candidate for actually performing offline (as opposed to within a single coursier run as coursier solve could), especially since it needs access to the actual artifacts instead of just POMs (and I believe also wouldn't allow for range intersections, just one-off pairings for binary compatibility). However we may develop heuristics to speed the process used for coursier solve so much that this could instead be proferred as a second-level check of sorts, under an additional flag, which the user would presumably specify after restricting the range to check a little bit. Or, we may be able to do this right before offering up a successful solution, in order to check our work.
Love the tooling in the scala ecosystem to make these complex verifications so easy to suggest in addition! :D

If we open the door to offline computation of metadata (which we would presumably then publish and sync by some mechanism for use in future solve runs), we can likely rely on the transitive property of compatibility to derive intersectionality from a linear set of pairwise comparisons. Unfortunately, mima exceptions are relatively commonplace (for good reason!) because it certainly isn't a tool that is free of false negatives, so I do wonder how feasible even the pairwise comparisons would be in general. We probably do need to rely on versioning assumptions (configurable on a per-artifact basis by the users).

This would likely cut down on wasteful scala-steward PRs which currently trigger failing builds, needlessly consuming compute resources for stuff that even if the tests pass, low test coverage could still produce faulty releases.
We'd lose out on the release notes and updates for new versions of libraries we care about, so an enhancement would be to make unsafe PRs either Draft (if draft PRs don't trigger CI builds) or Issues with the current PR description, with an additional note as to which dependencies are preventing the proper update.
This would have a knock-on effect of directing folk to exactly why a shiny new version is unavailable to them, hopefully promoting more community interaction on core infrastructure that may be getting less traction due to poor publicity.

This is a problem that we have some internal sbt tooling to detect and somewhat mitigate, but by no means automatically fix. Basically we have a company-wide plugin that has some wrappers on sbt's internals and, probably the most useful thing, a plugin that provides pinned versions of commonly-used libraries.
Feel free to ignore the tangential question, but I've always wondered if this problem is solve-able at the JVM level? Is there some fundamental reason why the JVM can't load classes from two different versions of a JAR? Obviously something like the proposed solution in coursier is still useful, and it's still bad practice to have bloated artifacts with multiple versions of a library. But it seems not totally crazy that the JVM could load classes from different versions of a library, whereas it seems virtually impossible to get all transitive deps lined up, especially across multiple repos.

Feel free to ignore the tangential question, but I've always wondered if this problem is solve-able at the JVM level? Is there some fundamental reason why the JVM can't load classes from two different versions of a JAR?

It is possible for a JVM to load classes from two different versions of a JAR. sbt compiling Scala 2.13 code even though sbt itself runs on a specific version of Scala 2.12 is a good example of that. sbt constructs a layered ClassLoader, and essentially run Scala compilation within a sandbox, like Inception. This is not trivial since in (functional) programming you typically want a value out of this operation, so you need to come up with a contraption that would survive the sandbox boundary. For sbt / Zinc, we use Java classes to carry the information out. This also means that your reasoning like a type A or org.slf4j.Logger or a singleton object points to the same thing universally within your code. Not any more. You'd have to carefully plan that it's a Logger called by library X1 called by library X2 etc. Same goes for configuration files, side effects etc.
Instead of a traditional function call, a better analogy for this technique is to think of it as an emulation of java -jar ..., like run, which could be useful in some situations, but I'm skeptical it can be a workaround for transitive library resolution issue.

Feel free to ignore the tangential question, but I've always wondered if this problem is solve-able at the JVM level? Is there some fundamental reason why the JVM can't load classes from two different versions of a JAR? Obviously something like the proposed solution in coursier is still useful, and it's still bad practice to have bloated artifacts with multiple versions of a library. But it seems not totally crazy that the JVM could load classes from different versions of a library, whereas it seems virtually impossible to get all transitive deps lined up, especially across multiple repos.

It's doable but hard. https://github.com/moditect/layrry is a pretty decent start on this front (works on top of the java module system).

Pants uses jarjar (org.pantsbuild:jarjar) to shade libraries of different versions! I believe that is what is being asked here -- I think that it would compose in a lovely way with this solve command to reduce bloat.

To rephrase (paraphrasing @eed3si9n from a chat), all shading allows is perhaps some more leeway with allowing some conflicting versions to coincide. This should increase the likelihood of coursier solve being able to find a satisfying set, if it can take advantage of not having to find a completely non-conflicting resolution through all transitive deps. But I don't think it actually "solves this problem at the JVM level" -- coursier solve is the key necessary to make progress towards an upgrade of the relevant dependencies, instead of just working around it.

authors: alexklibisz blast-hardcheese cosmicexplorer djspiewak eed3si9n keynmol

repo: coursier/coursier


text:
Feature Donate on Homepage

Is your feature request related to a problem? Please describe.
A donate page on the homepage of the site that will show all the official information on how a user can donate to for the cause. For Example : A section showing information on how to donate to PM Cares fund or State Govt. Funds and a section showing various NGOs to which donation can be made via UPI or Paytm or any other channel.
Describe the solution you'd like
Currently data will be updated to the google sheet database and fetched from there as done for other APIs like FAQ.
Describe alternatives you've considered
No alternative as this is the need of the hour. This will motivate people and even a small amount raised through it will be of high help.
Additional context
Future enhancements include showing Twitter and Instagram trends and post of users like celebs who are supporting so that more and more people will be encouraged to donate or come forward to help the needy and poor.
Sections will be like given below in screenshots.

@jeremyphilemon and Team, Kindly review the feature request.

Hi @smittal1209, I see that you've put a lot of thought into this. But please comment and continue the discussion on #672. It would be easier for us to track


text:
Moved Deltas Below Mini-Graphs

Moved deltas below mini-graphs
Changed color of "Last Updated Time"

Preview: https://covid19-india-react-git-ui-issues.s-naveen.now.sh/

@JunaidBabu @sudevschiz  I was asked to do this change this morning but not merged still. Is there any issue with this change?

Hey, so the I realized the missing active deltas would make the aligning a lot more weird. Let's have a chat with the layout changes for this :)
Closing this for now.

authors: jeremyphilemon s-naveen


text:
2020-04-15 Hotfix

RequestValidationResult wasn't decorated with Protobuf Contract attributes, so any validation problem using Accept: application/x-protobuf (which is the default) will always throw HTTP 500.

@ataymano please approve this hotfix when you're able. Upon completion it should automatically roll-out to production.

repo: covidsafe/Backend


text:
Add memorization to the bitMatrix class & return the transformation

Increased performance because we don't recreate the matrix for every scene.
the performance is way better for continuous streaming.
return the transformation matrix.

Note that the avoidance of buffer memory allocation and garbage collection for each scanned image is also achieved by #115.
#115 has the additonal advantage of no memory overhead, as no additonal memory has to be allocated or cached, in contrast to the Memo cache here that is on top never pruned.

authors: LHDi danimoh

repo: cozmo/jsQR


text:
Build errors on FreeBSD

I'm trying to build juCi++ on FreeBSD 10.3-Release which is my main development box. Unfortunately I'm getting a few build errors:
First it was not able to find libclang.so. That's because FreeBSD uses a different directory structure in order to allow the user install different compiler versions. So, I made the following changes:
cmake_modules/FindLibClang.cmake
find_path(LIBCLANG_INCLUDE_DIR clang-c/Index.h
  PATHS ${libclang_llvm_header_search_paths}
  PATH_SUFFIXES LLVM/include llvm33/include llvm34/include llvm35/include llvm36/include llvm37/include llvm38/include #Windows package from http://llvm.org/releases/
  DOC "The path to the directory that contains clang-c/Index.h")

# On Windows with MSVC, the import library uses the ".imp" file extension
# instead of the comon ".lib"
if (MSVC)
  find_file(LIBCLANG_LIBRARY libclang.imp
    PATH_SUFFIXES LLVM/lib llvm33/lib llvm34/lib llvm35/lib llvm36/lib llvm37/lib llvm38/lib
    DOC "The file that corresponds to the libclang library.")
endif()

find_library(LIBCLANG_LIBRARY NAMES libclang.imp libclang clang
  PATHS ${libclang_llvm_lib_search_paths}
  PATH_SUFFIXES LLVM/lib llvm33/lib llvm34/lib llvm35/lib llvm36/lib llvm37/lib llvm38/lib #Windows package from http://llvm.org/releases/
  DOC "The file that corresponds to the libclang library.")

Then cmake was successful:
-- The C compiler identification is Clang 3.4.1
-- The CXX compiler identification is Clang 3.4.1
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LibClang: /usr/local/llvm38/lib/libclang.so
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   regex
--   system
--   filesystem
-- Found ASPELL: /usr/local/lib/libaspell.so
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
-- Checking for module 'gtkmm-3.0'
--   Found gtkmm-3.0, version 3.16.0
-- Checking for module 'gtksourceviewmm-3.0'
--   Found gtksourceviewmm-3.0, version 3.2.0
-- Checking for module 'libgit2'
--   Found libgit2, version 0.24.0
-- Could NOT find plantuml (missing:  PLANTUML_JARFILE)
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/babaei/Desktop/jucipp/build

Now, I'm getting the following error at the build stage:
[  9%] Building CXX object src/CMakeFiles/project_shared.dir/git.cc.o
/home/babaei/Desktop/jucipp/src/git.cc:106:44: error: no member named
      'FILE_MONITOR_WATCH_MOVES' in 'Gio::FileMonitorFlags'; did you mean
      'G_FILE_MONITOR_WATCH_MOVES'?
  ...Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     G_FILE_MONITOR_WATCH_MOVES
/usr/local/include/glib-2.0/gio/gioenums.h:347:3: note:
      'G_FILE_MONITOR_WATCH_MOVES' declared here
  G_FILE_MONITOR_WATCH_MOVES      = (1 << 3)
  ^
/home/babaei/Desktop/jucipp/src/git.cc:106:26: error: no matching member
      function for call to 'monitor_directory'
  monitor=git_directory->monitor_directory(Gio::FileMonitorFlags::FILE_M...
	  ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/usr/local/include/giomm-2.4/giomm/file.h:2735:29: note: candidate function not
      viable: no known conversion from 'GFileMonitorFlags' to 'const
      Glib::RefPtr<Cancellable>' for 1st argument
  Glib::RefPtr<FileMonitor> monitor_directory(const Glib::RefPtr<Cancell...
	                    ^
/usr/local/include/giomm-2.4/giomm/file.h:2743:29: note: candidate function not
      viable: no known conversion from 'GFileMonitorFlags' to
      'Gio::FileMonitorFlags' for 1st argument
  Glib::RefPtr<FileMonitor> monitor_directory(FileMonitorFlags flags = F...
	                    ^
2 errors generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/home/babaei/Desktop/jucipp/build
*** Error code 1

Stop.
make[1]: stopped in /usr/home/babaei/Desktop/jucipp/build
*** Error code 1

Stop.
make: stopped in /usr/home/babaei/Desktop/jucipp/build

It seems cmake picks up the wrong version of gtkmm library since I do have two different version of it installed at the same time (despite the fact that it says it picked up version 3 of the library):
    $ pkg info | grep gtkmm
    gtkmm24-2.24.4_2               C++ wrapper for Gtk+
    gtkmm30-3.16.0                 C++ wrapper for Gtk+3

I'm really excited about this brand new IDE and like to check it out, or even create a port for it. So, any help would be greatly appreciated.

Thank you for testing on FreeBSD. There seems to be a version mismatch between your glib and glibmm. We should really test glibmm version instead of glib version here: https://github.com/cppit/jucipp/blob/master/src/git.cc#L107. I'll try fix it now.

Would you mind test the above commit?

Sorry, there was a similar check in src/directories.cc as well. I did a rebase too, please use the latest commit above.

Thank you so much for the quick reply. I'm not at home right now. But, I'll try to test and report back as soon as I can.

I just checked out the master branch and I'm getting the following error:
[ 12%] Building CXX object src/CMakeFiles/project_shared.dir/git.cc.o
/home/babaei/Desktop/jucipp-master/src/git.cc:108:44: error: no member named
      'FILE_MONITOR_WATCH_MOVES' in 'Gio::FileMonitorFlags'; did you mean
      'G_FILE_MONITOR_WATCH_MOVES'?
  monitor=git_directory->monitor_directory(Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES);
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           G_FILE_MONITOR_WATCH_MOVES
/usr/local/include/glib-2.0/gio/gioenums.h:347:3: note: 'G_FILE_MONITOR_WATCH_MOVES' declared
      here
  G_FILE_MONITOR_WATCH_MOVES      = (1 << 3)
  ^
/home/babaei/Desktop/jucipp-master/src/git.cc:108:26: error: no matching member function for
      call to 'monitor_directory'
  monitor=git_directory->monitor_directory(Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES);
          ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/usr/local/include/giomm-2.4/giomm/file.h:2735:29: note: candidate function not viable: no
      known conversion from 'GFileMonitorFlags' to 'const Glib::RefPtr<Cancellable>' for 1st
      argument
  Glib::RefPtr<FileMonitor> monitor_directory(const Glib::RefPtr<Cancellable>& cancell...
                            ^
/usr/local/include/giomm-2.4/giomm/file.h:2743:29: note: candidate function not viable: no
      known conversion from 'GFileMonitorFlags' to 'Gio::FileMonitorFlags' for 1st argument
  Glib::RefPtr<FileMonitor> monitor_directory(FileMonitorFlags flags = FILE_MONITOR_NONE);
                            ^
2 errors generated.
gmake[2]: *** [src/CMakeFiles/project_shared.dir/build.make:159: src/CMakeFiles/project_shared.dir/git.cc.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:125: src/CMakeFiles/project_shared.dir/all] Error 2
gmake: *** [Makefile:150: all] Error 2

What version of glib and glibmm do you have?

$ pkg info | grep glib
dbus-glib-0.104                GLib bindings for the D-BUS messaging system
glib-2.46.2_2                  Some useful routines of C programming (current stable version)
glib-networking-2.46.1_1       Network-related giomodules for glib
glibmm-2.44.0,1                C++ interfaces for glib2
json-glib-1.1.2                JSON (RFC 4627) interface for Glib
libgit2-glib-0.24.0            Glib wrapper library around the libgit2 git access library
poppler-glib-0.40.0            GLib bindings to poppler
taglib-1.10                    Library for manipulating ID3 tags and Ogg comments
telepathy-glib-0.24.1          GLib utility library for the Telepathy framework

That is strange, you have the required glibmm version (2.44) for Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES. You can however replace Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES with Gio::FileMonitorFlags::FILE_MONITOR_SEND_MOVED in src/git.cc and src/directories.cc.

Or, is there a separate giomm package on FreeBSD? In that case, what version is your gio and giomm?

Or, is there a separate giomm package on FreeBSD? In that case, what version is your gio and giomm?
No, there is not:
https://www.freebsd.org/cgi/ports.cgi?query=giomm&stype=name&sektion=all

That is strange, you have the required glibmm version (2.44) for Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES. You can however replace Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES with Gio::FileMonitorFlags::FILE_MONITOR_SEND_MOVED in src/git.cc and src/directories.cc.

Now I get an linker error, despite the fact that I have /usr/local/lib/libgtkmm-3.0.so on my system:
[41/41] Linking CXX executable src/juci
FAILED: src/juci
: && /usr/bin/CC   -DJUCI_VERSION=\"1.2.1\" -std=c++1y -pthread -Wall -Wextra -Wno-unused-parameter -Wno-reorder -O3   src/CMakeFiles/project_shared.dir/cmake.cc.o src/CMakeFiles/project_shared.dir/ctags.cc.o src/CMakeFiles/project_shared.dir/dispatcher.cc.o src/CMakeFiles/project_shared.dir/filesystem.cc.o src/CMakeFiles/project_shared.dir/git.cc.o src/CMakeFiles/project_shared.dir/project_build.cc.o src/CMakeFiles/project_shared.dir/source.cc.o src/CMakeFiles/project_shared.dir/source_clang.cc.o src/CMakeFiles/project_shared.dir/source_diff.cc.o src/CMakeFiles/project_shared.dir/source_spellcheck.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/CodeCompleteResults.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/CompilationDatabase.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/CompileCommand.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/CompileCommands.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/CompletionString.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Cursor.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Diagnostic.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Index.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/SourceLocation.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/SourceRange.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Token.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Tokens.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/TranslationUnit.cc.o src/CMakeFiles/project_shared.dir/__/libclangmm/src/Utility.cc.o src/CMakeFiles/project_shared.dir/__/tiny-process-library/process.cpp.o src/CMakeFiles/project_shared.dir/__/tiny-process-library/process_unix.cpp.o src/CMakeFiles/juci.dir/config.cc.o src/CMakeFiles/juci.dir/dialogs.cc.o src/CMakeFiles/juci.dir/dialogs_unix.cc.o src/CMakeFiles/juci.dir/directories.cc.o src/CMakeFiles/juci.dir/entrybox.cc.o src/CMakeFiles/juci.dir/info.cc.o src/CMakeFiles/juci.dir/juci.cc.o src/CMakeFiles/juci.dir/menu.cc.o src/CMakeFiles/juci.dir/notebook.cc.o src/CMakeFiles/juci.dir/project.cc.o src/CMakeFiles/juci.dir/selectiondialog.cc.o src/CMakeFiles/juci.dir/terminal.cc.o src/CMakeFiles/juci.dir/tooltips.cc.o src/CMakeFiles/juci.dir/window.cc.o  -o src/juci  -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lgio-2.0 -lcairomm-1.0 -lcairo -lpthread -lsigc-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lgtksourceviewmm-3.0 -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgtksourceview-3.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl /usr/local/lib/libboost_system.so /usr/local/lib/libboost_filesystem.so /usr/local/llvm36/lib/libclang.so /usr/local/lib/libaspell.so -lgit2 -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgtksourceviewmm-3.0 -lgtksourceview-3.0 /usr/local/lib/libboost_system.so /usr/local/lib/libboost_filesystem.so /usr/local/llvm36/lib/libclang.so /usr/local/lib/libaspell.so -lgit2 -Wl,-rpath,/usr/local/lib:/usr/local/llvm36/lib: && :
/usr/bin/ld: cannot find -lgtkmm-3.0
c++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

I should not that traditionally FreeBSD systems install all packages inside /usr/local and leaves the base system untouched by ports and packages. e.g:
/usr/local/lib
/usr/local/include
/usr/local/share
/usr/local/etc

Or, is there a separate giomm package on FreeBSD? In that case, what version is your gio and giomm?

No, there is not:
https://www.freebsd.org/cgi/ports.cgi?query=giomm&stype=name&sektion=all

$ pkg which /usr/local/include/giomm-2.4/giomm/file.h
/usr/local/include/giomm-2.4/giomm/file.h was installed by package glibmm-2.44.0,1

I fixed the gio check in https://github.com/cppit/jucipp/tree/freebsd I hope.
Regarding the linking error, try add -L/usr/local/lib to the compile flags, or modify the path to the libgtkmm-3.0.so(or something similar) file.

OK, thanks. I checked out the freebsd branch and the gio check issue still persists:
$ git status
On branch freebsd
Your branch is up-to-date with 'origin/freebsd'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   ../tiny-process-library (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

The actual build error:
Scanning dependencies of target project_shared
[  2%] Building CXX object src/CMakeFiles/project_shared.dir/cmake.cc.o
[  4%] Building CXX object src/CMakeFiles/project_shared.dir/ctags.cc.o
[  7%] Building CXX object src/CMakeFiles/project_shared.dir/dispatcher.cc.o
[  9%] Building CXX object src/CMakeFiles/project_shared.dir/filesystem.cc.o
[ 12%] Building CXX object src/CMakeFiles/project_shared.dir/git.cc.o
/usr/home/babaei/Desktop/jucipp-freebsd/src/git.cc:108:44: error: no member named
      'FILE_MONITOR_WATCH_MOVES' in 'Gio::FileMonitorFlags'; did you mean
      'G_FILE_MONITOR_WATCH_MOVES'?
  monitor=git_directory->monitor_directory(Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES);
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           G_FILE_MONITOR_WATCH_MOVES
/usr/local/include/glib-2.0/gio/gioenums.h:347:3: note: 'G_FILE_MONITOR_WATCH_MOVES' declared
      here
  G_FILE_MONITOR_WATCH_MOVES      = (1 << 3)
  ^
/usr/home/babaei/Desktop/jucipp-freebsd/src/git.cc:108:26: error: no matching member function
      for call to 'monitor_directory'
  monitor=git_directory->monitor_directory(Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES);
          ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/usr/local/include/giomm-2.4/giomm/file.h:2735:29: note: candidate function not viable: no
      known conversion from 'GFileMonitorFlags' to 'const Glib::RefPtr<Cancellable>' for 1st
      argument
  Glib::RefPtr<FileMonitor> monitor_directory(const Glib::RefPtr<Cancellable>& cancell...
                            ^
/usr/local/include/giomm-2.4/giomm/file.h:2743:29: note: candidate function not viable: no
      known conversion from 'GFileMonitorFlags' to 'Gio::FileMonitorFlags' for 1st argument
  Glib::RefPtr<FileMonitor> monitor_directory(FileMonitorFlags flags = FILE_MONITOR_NONE);
                            ^
2 errors generated.
gmake[2]: *** [src/CMakeFiles/project_shared.dir/build.make:159: src/CMakeFiles/project_shared.dir/git.cc.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:125: src/CMakeFiles/project_shared.dir/all] Error 2
gmake: *** [Makefile:150: all] Error 2

In addition to that now I noticed that CMake is not able to find liblldb in both master and freebsd branches. In the cmake_modules/FindLibClang.cmake file I manipulated from v1.2.0 tag there is no warning about liblldb is missing:
-- The C compiler identification is Clang 3.4.1
-- The CXX compiler identification is Clang 3.4.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/CC
-- Check for working CXX compiler: /usr/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LibClang: /usr/local/llvm36/lib/libclang.so
liblldb not found. Building juCi++ without debugging support
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   system
--   filesystem
-- Found ASPELL: /usr/local/lib/libaspell.so
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
-- Checking for module 'gtkmm-3.0'
--   Found gtkmm-3.0, version 3.16.0
-- Checking for module 'gtksourceviewmm-3.0'
--   Found gtksourceviewmm-3.0, version 3.2.0
-- Checking for module 'libgit2'
--   Found libgit2, version 0.24.0
-- Could NOT find plantuml (missing:  PLANTUML_JARFILE)
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/home/babaei/Desktop/jucipp-freebsd/build

Thank you very much for testing this! According to https://developer.gnome.org/glibmm/stable/group__giommEnums.html#ga469f795e9a4dddb2421c0e5568be6649, the check is correct in master branch. Not sure how to fix the compilation error actually, other than doing the manual replace.
Where is your liblldb located? I might need the full path and file name.

OK, I found the issue with: liblldb not found. Building juCi++ without debugging support
I have 3 versions of LLVM installed at the same time:
/usr/local/llvm36
/usr/local/llvm37
/usr/local/llvm38

Now if change the following lines inside ./cmake_modules/FindLibClang.cmake from
find_path(LIBCLANG_INCLUDE_DIR clang-c/Index.h
  PATHS ${libclang_llvm_header_search_paths}
  PATH_SUFFIXES LLVM/include #Windows package from http://llvm.org/releases/
    llvm33/include llvm34/include llvm35/include llvm36/include llvm37/include llvm38/include llvm39/include # FreeBSD
  DOC "The path to the directory that contains clang-c/Index.h")

find_library(LIBCLANG_LIBRARY NAMES libclang.imp libclang clang
  PATHS ${libclang_llvm_lib_search_paths}
  PATH_SUFFIXES LLVM/lib #Windows package from http://llvm.org/releases/
    llvm33/lib llvm34/lib llvm35/lib llvm36/lib llvm37/lib llvm38/lib llvm39/lib # FreeBSD
  DOC "The file that corresponds to the libclang library.")

To, for example
find_path(LIBCLANG_INCLUDE_DIR clang-c/Index.h
  PATHS ${libclang_llvm_header_search_paths}
  PATH_SUFFIXES LLVM/include #Windows package from http://llvm.org/releases/
    llvm38/include # FreeBSD
  DOC "The path to the directory that contains clang-c/Index.h")

find_library(LIBCLANG_LIBRARY NAMES libclang.imp libclang clang
  PATHS ${libclang_llvm_lib_search_paths}
  PATH_SUFFIXES LLVM/lib #Windows package from http://llvm.org/releases/
    llvm38/lib # FreeBSD
  DOC "The file that corresponds to the libclang library.")

CMake won't get confused and won't spit out that warning.

Thank you very much for testing this! According to https://developer.gnome.org/glibmm/stable/group__giommEnums.html#ga469f795e9a4dddb2421c0e5568be6649, the check is correct in master branch. Not sure how to fix the compilation error actually, other than doing the manual replace.

Maybe an #if defined ( __FreeBSD__ ) is necessary on that check.
I'll try to make it work and make the necessary patches with your approval.

Thank you, I'll change the search order so that the newest version is checked first. I also removed older llvm versions. llvm 3.6 should probably be minimum.

That would be great @NuLL3rr0r

When I think about it, the gio build error might be a glibmm issue on freebsd, so the #if check might be needed as a workaround.

Well, I investigated that http://svnweb.freebsd.org/ports/head/devel/glibmm/
In the Makefile the MASTER_SITES variable points to gnome official website and if you check the distinfo file the sha hash is the same. Moreover, in FreeBSD Ports system if they patch a port/package there should be a files folder too which is not there (all patch files go into that folder). So, the package is a vanilla upstream package.

The file operations are very platform dependent. What I'm thinking is that, Gio::FileMonitorFlags::FILE_MONITOR_WATCH_MOVES is missing or not implemented in your version of glibmm. Since it might be implemented in glib (the C-library), this might be an issue with glibmm where there might be an incorrect platform check. I've seen this before for gtksourceview (and posted a fix) for MSYS2. This is only a hunch though, the problem might lie elsewhere.

Thanks for the info, I'm not familiar with these gtk stuff. So, perhaps your guess might be correct. I checked this package maintainer's email and it's the FreeBSD Gnome Team at gnome@FreeBSD.org. Probably they are the best to ask.

I'll have a look at the glibmm bug reports and the source code later in a day or two. We probably have to add the #if defined ( __FreeBSD__ ) expression anyway though, since a potential fix would not arrive until a later glibmm version.

Thank you so much. Now I'm able to build and install it on my FreeBSD system. I'll try to create a FreeBSD port and submit it for review on FreeBSD ports tree.
Looks promising BTW! Thanks for the great work.

Thank you as well! Let me know if there are any more issues on FreeBSD. I guess it's about time I give FreeBSD a try too, maybe next week:)

My pleasure! That's awesome :) I'm sure you'll like it.

repo: cppit/jucipp


text:
[Context] Add support for float32 texture internal formats

Previously, float32 textures were normalized to [0, 1] by the Texture
constructor.

Thank you!


authors: brynrhodes csandersdev joelmontavon


text:
invalid syntax

I got an error in the launch.py:32 called invalid syntax
I installed the Dependencies with no error.

What python version are you running with?

It was that sorry in terminal I've alias python -> python3 and I forgot to change it.
Thanks <3

authors: Shirobachi crabvk

repo: crabvk/polybar-gmail


text:
duplication problem

I am using this selector ( onmousedown ontouchend ) , some time the pop up show twice on mobile and some time on pc
using jquery-confirm v3.2.0
I want to update to jquery-confirm v3.2.3 but i am not sure if that will break anything   , so i want to be sure
1- how prevent duplication of the pop up
2- is it a bug
3- can i upgrade safely
Regards

Please post your code for clear understanding,

i dont like this way , the author of the lib has to provide a fix for this with big Thanks for hem for sure !

Thanks for pointing the issue @snap608 , i should be checking if the events are already binded. Will fix asap.
@instagramlover

as @snap608 pointed out, its because multiple events are attached, this is to be fixed.
Yes, its a bug
Yes, look for the changes that were made between the versions.
If the changes are breaking older versions i will surely point it out in the release notes.

Dear @craftpip , please can you explain this :

function popupalert(title, text, reload) {
      $.alert({
          title: title,
          content: text,
          confirmButton: 'Ok',
          boxWidth: '30%',
          useBootstrap: false,
          icon: 'ui large red warning circle icon',
          animation: 'zoom',
          buttons: {
              close: {
                  btnClass: 'btn-blue',
                  action: function() {
                      if (reload) {
                          location.reload();
                      }
                  }
              }
          }
      })
  }

$(".globalbody").on("touchend mousedown", ".add_mor_time_sign", function() {
              popupalert('Error!', 'There is no enough time in your global account balance Please Buy more time!', false);
  })

the problem still available !

authors: craftpip historylife instagramlover

repo: craftpip/jquery-confirm


text:
Add support for latest RN builds

The latest versions of RN dropped support for double quote imports entirely.
As a result, the conditional compile in the header file causes iOS builds to fail on the latest versions of RN.
Removing the older double-quote import fixes it, but also means that the tokenizer will now no longer work on really, really old versions of RN.

Thanks!


text:
How to capture exceptions inside postmark api

I am getting exceptions in my log for certain emails when people try resetting their password.
(see below) - Is there a recommended way of capturing those or avoiding these altogether?
Using latest version 2.4 with laravel 5.8.8
Message
Client error: `POST https://api.postmarkapp.com/email` resulted in a `422 Unprocessable Entity` response:
{"ErrorCode":406,"Message":"You tried to send to a recipient that has been marked as inactive.\nFound inactive addresses (truncated...)
Level
ERROR
Exception
```{
   "class": "GuzzleHttp\\Exception\\ClientException",
   "message": "Client error: `POST https:\/\/api.postmarkapp.com\/email` resulted in a `422 Unprocessable Entity` response:\n{\"ErrorCode\":406,\"Message\":\"You tried to send to a recipient that has been marked as inactive.\\nFound inactive addresses (truncated...)\n",
   "code": 422,
   "file": "\/home\/forge\/www.nanochipid.com\/releases\/20190414015353\/vendor\/guzzlehttp\/guzzle\/src\/Exception\/RequestException.php:113",
   "trace": [
...

Hey @mberneis, I have gotten those errors before, but its actually stating that this specific recipient has been marked as inactive. I'm not sure what this package can do (if anything) to assist in this situation, but if you have any suggestions beyond what postmark recommends in the link above, please let me know 👍

Thank you for the quick response - Yes, I would prefer just to get a Log::warning instead of the exception. Maybe there could be a configuration setting and the exception can be caught when calling guzzle. Would you think that might be a worthwhile feature? - If so I will start working on a PR

I would have no objection to it, as long as its opt-in by default since it deviates from how Laravel's built in transports work 👍

@mberneis, I know this is an old (and closed) issue but I am trying to do the same - capturing the 422 exception but haven't been able to figure out how to do this yet. Any insights would be greatly appreciated. I also see there is an open issue to handle exceptions better but it is slated for [3.x] https://github.com/craigpaul/laravel-postmark/issues/89

authors: benlwong craigpaul mberneis

repo: craigpaul/laravel-postmark


text:
Add Table Policy documentation

What's Inside
Documentation of new feature - Table Policies
Preview
https://crate-cloud--72.org.readthedocs.build/en/72/reference/overview.html#table-policies
Highlights

What the feature does
How to get to it
Configuration
Logs

Checklist

[ ] Link to issue this PR refers to (if applicable):
[x] CLA is signed

Can we maybe add an example?

e.g. set replicas to 0 for data older than 30 days -> to save space for the replica with the assumption it is already available in a snapshot
delete data that is older than 60 days

could be very simple
CREATE TABLE data_table (
   ts TIMESTAMP
   ts_day GENERATED ALWAYS AS date_trunc('day',ts),
   val DOUBLE
) PARTITIONED BY (ts_day);

Something like this? https://github.com/crate/cloud-docs/pull/72/files#diff-88ca359c1e314aab139ab284940806ab980c28bc964aef99f258756727c5b47fR790
Also, I meant to ask about the segment merge action. I'm not completely clear what it does😅
And also couldn't find much about it on CrateDB docs. Could you explain please? I think I should clarify it, or add a note maybe @proddata

authors: matkuliak proddata

repo: crate/cloud-docs


text:
Don't execute lines containing only whitespaces

A file with trailing whitespace could lead to something like this:
CONNECT OK
DROP OK, 1 row affected  (0.058 sec)
CREATE OK, 1 row affected  (0.193 sec)
SQLActionException[Failed to parse source [{"stmt": ""}]]

Coverage remained the same at 83.982% when pulling 139f4b9b3d3ea138280926f932f03f0bfd809585 on j/remove-empty-line into 2c24accedb3f95e09861c982b5a06c4a39ad8523 on master.

Codecov Report

Merging #238 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #238   +/-   ##
=======================================
  Coverage   83.98%   83.98%
=======================================
  Files          19       19
  Lines        2235     2235
=======================================
  Hits         1877     1877
  Misses        358      358

Impacted Files
Coverage Δ

src/crate/crash/command.py
86.45% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

changelog entry?

I think that code was still unreleased and in the released version it appears to have been ignored already

authors: codecov-io coveralls mfussenegger

repo: crate/crash


text:
added missing test for parsing http url

updated Crate to 0.55.2 (stable)

ack

authors: kovrus mikethebeer

repo: crate/crate-python


text:
Bundled JDK23 has a performance regression in memory segment access

CrateDB version
master
Observed behavior
See

https://github.com/elastic/elasticsearch/issues/113030
https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
https://bugs.openjdk.org/browse/JDK-8341127

Spot this while looking at one of the JFR recordings and saw that AbstractMemorySegmentImpl appears in 2 hotspots, see picture below

Possible solutions

Port https://github.com/opensearch-project/OpenSearch/pull/16342
Wait for the JDK 23.0.2 release, according to the https://www.java.com/releases/, it's planned to be released on  2025-01-21

Spot this while looking at one of the JFR recordings and saw that AbstractMemorySegmentImpl appears in 2 hotspots

Actually, those recordings are most likely taken on released versions and not on nightly and in 5.9 we don't use JDK 23.
So this issue is mostly related to 5.10.
Regarding the screenshot: memory segment access can be still a hotspot in 5.9 but it could be a separate issue

Yes so this is confusing now :-)
I would  suggest you rewrite this issue so that it's about what we observed in the JFR recorded on CrateDB 5.8 and JDK 22.
I'd say a JDK23 issue isn't even needed, or if you want to look into it, then please create a repro that shows an actual problem with CrateDB 5.10 and then create a new issue for that.

I would suggest you rewrite this issue so that it's about what we observed in the JFR recorded on CrateDB 5.8 and JDK 22.

Done.
Just for tracking (on case it's somehow related): here is JDK23 regression related links

https://github.com/elastic/elasticsearch/issues/113030
https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
https://bugs.openjdk.org/browse/JDK-8341127

authors: BaurzhanSakhariev henrikingo

repo: crate/crate