HBASE-22690 Deprecate / Remove OfflineMetaRepair in hbase-2+

This is for branch-2. I changed OfflineMetaRepair to output a message pointing user to hbck2 operator tools and removed some unnecessary logics in HBaseFsck.

Other than the suggestions from @busbey and @HorizonNet , lgtm. Tested that hbck readonly options still work, and trying to run OMR gives the warning message without doing anything.

Should we squash this PR @brfrn169 given you opened new one sir. Does new one address above comments? Thanks.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
220
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2 Compile Tests _

+1
mvninstall
260
branch-2 passed

+1
compile
59
branch-2 passed

+1
checkstyle
73
branch-2 passed

+1
shadedjars
234
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
165
branch-2 passed

+1
javadoc
36
branch-2 passed

_ Patch Compile Tests _

+1
mvninstall
234
the patch passed

+1
compile
53
the patch passed

+1
javac
53
the patch passed

-1
checkstyle
68
hbase-server: The patch generated 4 new + 103 unchanged - 4 fixed = 107 total (was 107)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
246
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
709
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
findbugs
170
the patch passed

+1
javadoc
36
the patch passed

_ Other Tests _

-1
unit
19226
hbase-server in the patch failed.

+1
asflicense
30
The patch does not generate ASF License warnings.

22126

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestRestoreSnapshotFromClientSimple

hadoop.hbase.client.TestSnapshotDFSTemporaryDirectory

hadoop.hbase.client.TestFromClientSideWithCoprocessor

hadoop.hbase.replication.TestReplicationKillSlaveRS

hadoop.hbase.client.TestAsyncTableAdminApi

hadoop.hbase.client.TestCloneSnapshotFromClientNormal

hadoop.hbase.replication.TestMasterReplication

hadoop.hbase.client.TestSnapshotTemporaryDirectory

hadoop.hbase.client.TestFromClientSide

hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas

hadoop.hbase.client.replication.TestReplicationAdminWithClusters

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/380

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux bb5bc6b2b717 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
branch-2 / b6569442ef

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/testReport/

Max. process+thread count
4575 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

Thank you for reviewing guys.
I modified the patch for the review. Could you please review it? @busbey @HorizonNet

Should we squash this PR @brfrn169 given you opened new one sir. Does new one address above comments? Thanks.

@saintstack The new one means this PR, right?
https://github.com/apache/hbase/pull/381
That is for the master branch. In that PR, I removed OfflineMetaRepair completely whereas in this PR (for branch-2), I changed OfflineMetaRepair to output a message pointing user to hbck2 operator tools.
My intention is to deprecate in 2.x and to remove in 3.0.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
244
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2 Compile Tests _

+1
mvninstall
455
branch-2 passed

+1
compile
68
branch-2 passed

+1
checkstyle
94
branch-2 passed

+1
shadedjars
320
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
212
branch-2 passed

+1
javadoc
42
branch-2 passed

_ Patch Compile Tests _

+1
mvninstall
297
the patch passed

+1
compile
68
the patch passed

+1
javac
68
the patch passed

-1
checkstyle
82
hbase-server: The patch generated 4 new + 103 unchanged - 4 fixed = 107 total (was 107)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
311
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
914
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
findbugs
191
the patch passed

+1
javadoc
40
the patch passed

_ Other Tests _

-1
unit
16102
hbase-server in the patch failed.

+1
asflicense
42
The patch does not generate ASF License warnings.

19859

Reason
Tests

Failed junit tests
hadoop.hbase.master.procedure.TestSCPWithReplicasWithoutZKCoordinated

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/380

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux cf3abb244e15 4.4.0-143-generic #169-Ubuntu SMP Thu Feb 7 07:56:38 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
branch-2 / 76c080b339

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/testReport/

Max. process+thread count
4887 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

I fixed some checkstyle warnings.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
34
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2 Compile Tests _

+1
mvninstall
238
branch-2 passed

+1
compile
52
branch-2 passed

+1
checkstyle
70
branch-2 passed

+1
shadedjars
240
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
151
branch-2 passed

+1
javadoc
34
branch-2 passed

_ Patch Compile Tests _

+1
mvninstall
231
the patch passed

+1
compile
51
the patch passed

+1
javac
51
the patch passed

+1
checkstyle
67
hbase-server: The patch generated 0 new + 101 unchanged - 6 fixed = 101 total (was 107)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
241
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
715
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
findbugs
142
the patch passed

+1
javadoc
32
the patch passed

_ Other Tests _

+1
unit
7803
hbase-server in the patch passed.

+1
asflicense
27
The patch does not generate ASF License warnings.

10444

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/380

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux 9cc36205b412 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
branch-2 / 6c834b974c

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/3/testReport/

Max. process+thread count
4637 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/3/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

Ping @busbey @HorizonNet @saintstack

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
85
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2 Compile Tests _

+1
mvninstall
267
branch-2 passed

+1
compile
58
branch-2 passed

+1
checkstyle
89
branch-2 passed

+1
shadedjars
285
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
216
branch-2 passed

+1
javadoc
87
branch-2 passed

_ Patch Compile Tests _

+1
mvninstall
278
the patch passed

+1
compile
61
the patch passed

+1
javac
61
the patch passed

+1
checkstyle
84
hbase-server: The patch generated 0 new + 101 unchanged - 6 fixed = 101 total (was 107)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
266
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
817
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
findbugs
165
the patch passed

+1
javadoc
35
the patch passed

_ Other Tests _

-1
unit
15719
hbase-server in the patch failed.

+1
asflicense
32
The patch does not generate ASF License warnings.

18914

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestFromClientSide

hadoop.hbase.quotas.TestClusterScopeQuotaThrottle

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/380

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux b508e2f9e409 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
branch-2 / 6fb03e63b6

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/4/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/4/testReport/

Max. process+thread count
4626 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/4/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
250
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2 Compile Tests _

+1
mvninstall
404
branch-2 passed

+1
compile
77
branch-2 passed

+1
checkstyle
106
branch-2 passed

+1
shadedjars
331
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
45
branch-2 passed

0
spotbugs
246
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
244
branch-2 passed

_ Patch Compile Tests _

+1
mvninstall
327
the patch passed

+1
compile
64
the patch passed

+1
javac
64
the patch passed

+1
checkstyle
91
hbase-server: The patch generated 0 new + 101 unchanged - 6 fixed = 101 total (was 107)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
289
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1022
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
javadoc
40
the patch passed

+1
findbugs
232
the patch passed

_ Other Tests _

-1
unit
18925
hbase-server in the patch failed.

+1
asflicense
31
The patch does not generate ASF License warnings.

22889

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestAsyncSnapshotAdminApi

hadoop.hbase.client.TestFromClientSideWithCoprocessor

hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas

hadoop.hbase.client.TestFromClientSide

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/380

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 78b37afb3f2b 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-380/out/precommit/personality/provided.sh

git revision
branch-2 / c54085a8d9

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/5/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/5/testReport/

Max. process+thread count
4433 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/5/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Thank you for reviewing @saintstack. I'll commit this.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
13
https://github.com/apache/hbase/pull/380 does not apply to branch-2. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/380

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/6/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
12
https://github.com/apache/hbase/pull/380 does not apply to branch-2. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/380

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/1/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
14
https://github.com/apache/hbase/pull/380 does not apply to branch-2. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/380

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-380/2/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


Module not found: Can't resolve 'amazon-cognito-identity-js'

I see this after following the installation instructions:
Failed to compile

./node_modules/ra-cognito/dist/AuthProvider/index.js
Module not found: Can't resolve 'amazon-cognito-identity-js' in '/home/berend/src/angrycactus/libya/admin/node_modules/ra-cognito/dist/AuthProvider'

I got past this with:
npm install amazon-cognito-identity-js

But then got:
Failed to compile

./node_modules/ra-cognito/dist/AuthProvider/index.js
Module not found: Can't resolve 'aws-amplify' in '/home/berend/src/angrycactus/libya/admin/node_modules/ra-cognito/dist/AuthProvider'

I installed that, and then got:
Failed to compile

./node_modules/ra-cognito/dist/AuthProvider/index.js
Module not found: Can't resolve 'ramda' in '/home/berend/src/angrycactus/libya/admin/node_modules/ra-cognito/dist/AuthProvider'

Solved this and the final one with:
npm install ramda redux-form

Shouldn't the package lists its dependencies more properly in the "dependencies" section? This is just unnecessarily tedious.

Hey @jsh8w, has there been any progress on the new version?

Just ran into this. Seems like these amplify, ramba, cognito, etc... are all required dependencies - not peer dependencies as they don't specify any specific version requirements beside the typical greater than some version at dev time.
I had to additionally install
npm install amazon-cognito-identity-js aws-amplify prop-types ramda recompose redux-form

I don't think you should consider users to have these requirements in their package before they try and use ra-cognito.

I did not realise this component requires amplify lib. Does this mean this lib has to be used together with amplify? I have a SPA with lambda, guess that won't meet the requirement?


[QUESTION] Why is SKSurface.Create returning null? (OpenGL)

I'm trying to understand why surface creation is failing.
I'm trying to use SkiaSharp without relying on OpenTK, or WinForms or the built-in views.

surface = SKSurface.Create(grContext, renderTarget, surfaceOrigin, colorType);

returns null. - but why?
The OpenGL Context looks valid. I have a valid GRContext. The Width and Height are not negative (which apparently tripped up a few people). I am using the platform color type static enum reference as required. [ SKImageInfo.PlatformColorType ]
Looking at the output produced in Immediate Window below, is there anything suspect to look into?
colorType
Bgra8888
surfaceOrigin
BottomLeft
renderTarget
{SkiaSharp.GRBackendRenderTarget}
Backend: OpenGL
Handle: 0x00000285eeb22ca0
Height: 720
IgnorePublicDispose: false
IsDisposed: false
IsValid: true
OwnsHandle: true
Rect: {{Left=0,Top=0,Width=1280,Height=720}}
SampleCount: 1
Size: {{Width=1280, Height=720}}
StencilBits: 8
Width: 1280
grContext
{SkiaSharp.GRContext}
Backend (SkiaSharp.GRRecordingContext): OpenGL
Backend: OpenGL
Handle: 0x00000285f1783eb0
IgnorePublicDispose: false
IsAbandoned: false
IsDisposed: false
OwnsHandle: true

Diving into the source of SkiaSharp for Create and stepping through, It looks like

GetObject(SkiaApi.sk_surface_new_backend_texture(context.Handle, texture.Handle, origin, sampleCount, colorType.ToNative(), colorspace?.Handle ?? IntPtr.Zero, props?.Handle ?? IntPtr.Zero));

Is returning null.


Add incremental annotation processing support to assisted inject.

Done!

I did aggregating because there are multiple originating elements. The
multiple elements in different are combined to create the assisted module.
Is that correct?
Le ven. 5 juil. 2019 à 23:37, Jake Wharton<EMAIL_ADDRESS>a
écrit :

@JakeWharton commented on this pull request.
In
assisted-inject-processor/src/main/java/com/squareup/inject/assisted/processor/AssistedInjectProcessor.kt
https://github.com/square/AssistedInject/pull/100#discussion_r300800471:

@@ -50,6 +52,7 @@ import javax.lang.model.util.Types
import javax.tools.Diagnostic.Kind.ERROR
import javax.tools.Diagnostic.Kind.WARNING

+@IncrementalAnnotationProcessor(AGGREGATING)
Why is this aggregating? We generate one type per annotated class.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/square/AssistedInject/pull/100?email_source=notifications&email_token=AACRGNPJ3YPAYIWHYPLXO2DP565KVA5CNFSM4H5XN4FKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5UTXAQ#pullrequestreview-258554754,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACRGNLA4QQROQ7NZSMHPITP565KVANCNFSM4H5XN4FA
.

That's for the Dagger 2 processor. I was asking about the factory processor.


Use DataDog API instead of Agent in Render

This is one approach to #912. I started with the idea that “hot-shots and datadog-metrics have basically the same API, so we can just choose which agent and expose it! Minimal change!” But of course nothing ever quite works out that simply. (It pans out for most callsites, but configuration so it mostly matches DogStatsD’s behavior and tests are both messy.) I stopped here to keep the changes (and my time investment) reasonably small.
This works well enough to probably be worth trying, but some other possible approaches:

Instead of swapping between the two, replace some callsites with the API and leave others pointing to the StatsD/hot-shots implementation.

Abstract this into a “metrics” module (or some similar name), which chooses where and how to send (maybe even other providers instead of DD in the future? 🤷). This probably makes sense to do regardless and a future change.

Separate the middleware from the DataDog client configuration. The way they are currently tied together makes the tests messier than they need to be (you can’t mock the DataDog client, or only sort-of can). Doing the above abstraction probably necessarily implies making this change, too. I didn’t do it here because I was trying to keep the scope smaller.

Putting this on hold for now. Even though we’re in a weird spot, where the loader uses the Datadog API but the server uses statsD and the Datadog Agent, there are some issues where posts to the API occasionally fail and I’m not confident in switching the server (questions to answer: are retries happening? how often is the agent dropping things for similar reasons?)

In the intervening time:

We rolled back the switch to Render, and this became not as big a deal. (Although different parts of the codebase communicating with Datadog in different was is slightly confusing and lame.)
Lots of surrounding code has changed, and this needs extensive rebasing and cleanup.

So some significant rework is needed here. But we've also shut down the production version of this project, and this work is probably not worthwhile in the end. I’m closing this PR.


How do I change the font size of text charactor?

I want to partially resize the text to be displayed.
Is that possible?
I am looking for a method other than segmented display.
I looked for celloption inside godoc but could not find an instruction to achieve font resizing.
<EMAIL_ADDRESS>I wanted to put up a Question label but could not.
Sorry.

Thank you for reaching out @ETC-kintaka. The font size isn't controlled by Termdash. Termdash runs on top of a terminal that is configured with a particular font size. When Termdash prints characters, they will be printed in the font size configured on the terminal.
To increase the font size, you would have to configure a different or larger font in the terminal emulator.
You are right that the segment display works around it, it draws larger characters. This is achieved by no longer using fonts, but drawing all characters a point at a time.

Thank you for contacting us.
Understood.
The font size is determined by the font specification in Terminal.
If you want the numbers to appear larger, use the segmented display.
I thank you again.


TypeError: Cannot read property 'vi' of undefined

I have installed via npm install twitter-cldr. I'm then load the vi locale that should be in the module assets here
> var TwitterCldr = require('twitter_cldr').load('vi');
undefined
> var iterator = new TwitterCldr.BreakIterator ("vi", {"use_uli_exceptions" : true});
undefined
> iterator.each_sentence("Trường đại học Bách Khoa Hà Nội");
TypeError: Cannot read property 'vi' of undefined
    at BreakIterator.TwitterCldr.BreakIterator.BreakIterator.tailoring_resource_for (/Users/loretoparisi/Documents/Projects/node_modules/twitter_cldr/full/core.js:1661:69)
    at BreakIterator.TwitterCldr.BreakIterator.BreakIterator.compile_rules_for (/Users/loretoparisi/Documents/Projects/node_modules/twitter_cldr/full/core.js:1590:38)
    at BreakIterator.TwitterCldr.BreakIterator.BreakIterator.each_boundary (/Users/loretoparisi/Documents/Projects/node_modules/twitter_cldr/full/core.js:1529:20)
    at BreakIterator.TwitterCldr.BreakIterator.BreakIterator.each_sentence (/Users/loretoparisi/Documents/Projects/node_modules/twitter_cldr/full/core.js:1510:19)
    at repl:1:10
    at sigintHandlersWrap (vm.js:22:35)
    at sigintHandlersWrap (vm.js:96:12)
    at ContextifyScript.Script.runInThisContext (vm.js:21:12)
    at REPLServer.defaultEval (repl.js:346:29)
    at bound (domain.js:280:14)

Hey @loretoparisi, thanks for the bug report! I spent some time over the weekend digging into this, and it appears to be fairly complex. Just wanted to acknowledge the issue though. I'll keep you apprised as I make progress :)

@loretoparisi I decided to build a new package for text segmentation and just released it via npm. It's called cldr-segmentation. Let me know if it meets your needs :)

@camertron this is awesome!!! Also it will help a lot, a I can easily integrate it now (I'm dealing with 20+ languages (word boundary and not) and twitter-cldr is the best implementation currently as segmentation tool for node.js
Thanks a lot.

Awesome, glad you're finding it useful!


Resolve remaining IPLD questions

@mildred and i discussed where IPLD should go and what to do with the JSON-LD trickiness encountered. We should finish resolving what the plan is and document it here.

In IRC we found that it was possible to put in the context a @container: @index that can, on one level only, make a JSON-LD processor not discard the keys, and instead treat the whole object as a map: a set of objects that can be identified using a key.
If we want that on the top level, though, I don't think we can have a @context explicit on the JSON. We need to transmit the context out of band. This is possible using the HTTP Link header, and we could arrange for similar ways to do that.
We must then arrange for the Node type to contain the link to the context separated from the data.

8:47  jbenet: I suspect that JSON-LD is going to be slower than our current IPFS objects.

not by a ton. we could benchmark this. i expect a constant increase, not orders of magnitude.

We would need to have the context object and execute a full JSON-LD processor to be able to get the list of links. It's not strainghtforward.

Why cant we grab them like this: https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122-L158 ? Are you worried about people remapping things to be mlinks that we wouldn't know about?

Why cant we grab them like this: https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122-L158 ? Are you worried about people remapping things to be mlinks that we wouldn't know about?

You can't be sure what name has a type unless you parse the context. There are multiple issues there:

the mlink type has been renamed by the context to mean something else
you might find that the mlink key has been used as part of a @container: @index (a map) instead of a linked data node.
the JSON might define the links using some other names than mlink, the context can define another name to refer to the mlink type, or the JSON might use the mlink URI in full
this information might not even be available in the JSON directly as contexts can be linked instead of embedded.

There are other issues about your flattened map, it looses all the semantic from JSON-LD in my opinion, for few reasons:

You don't have full control over the keys you use in JSON-LD. Keys generally means a type (with the exception of `@container: @index). You can't name your links the way you want. If the objective is to have those be paths in the IPFS path, this is a problem.
What do you do if you have JSON arrays? [...], how do you flatten them?
What about keys containing / characters in them. Such as full URI. This is specifically possible: See example 2 at http://www.w3.org/TR/json-ld/#basic-concepts

I think we should choose: If we want to be JSON-LD compatoble, we should't impose too much restrictions. And a JSON-LD author will find it difficult to find a way to describe a document with all these restrictions. The other solution is to support JSON-LD in full, but this is not as easy as parsing JSON. We should recognize that.
Or else, we should find another way to be compatible, or define the level of compatibility we want.
But please don't call JSON-LD what it is merely a subset.

Perhaps we could imagine to require a flattened JSON-LD when we want to store it: http://www.w3.org/TR/json-ld/#flattened-document-form
From the spec:

This ensures a shape of the data and consequently may drastically simplify the code required to process JSON-LD in certain applications

This is great because we write the object once, but read it many times.

Snips from the channel:

mildred: We can interpret the IPFS dialect find using JSON-LD. But IPFS won't be able to interpret any kind of JSON-LD for obvious performance reasons among other things
jbenet: JSON-LD is a strict subset of JSON, so by making a JSON transport, we can transparently address JSON-LD data
mildred: It will be able to hold any linked data provided it is compatible with our format

More notes
@diasdavid and I resolved that the main feature we want/need from JSON-LD at the moment is just the @context aliasing, and that it's a great place to start with such a dialect.
All we need to practically implement the aliasing is a module that provides aliasing expand function based on given contexts. The gist is this:
var expand = require('ipld-expand')

var jsonObjEmbedded = {
  "@context": [
      schema["@context"]
    ]
  "foo": {
    "mlink": "<hash>"
  }
}

console.log(expand(jsonObj))
// {
//   "foo": {
//     "/ipfs/<hash-of-mlink>/mlink": "<hash>"
//   }
// }

// now suppose we have a separate context
var schema = {
  "@context": {
     "mlink": "/ipfs/<hash-of-mlink>/mlink"
  }
}

// expand takes the object to expand, and a map of "url : contextObj".
// (so expand doesnt retrieve anything, it's already retrieved.)
expand({
    "@context": "/ipfs/aaaaa/ipld",
    "foo": { "mlink": "<hash>" }
}, {
    "/ipfs/aaaaa/ipld": schema,
    "/ipfs/bbbbb/bbb": {...},
    "/ipfs/cccccc/ccc": {...}
})

// another option is to do it with an object that supports "get(url)". so
// it could be backed by a simple map (like here), or by http or ipfs proper
expand({
    "@context": "/ipfs/aaaaa/ipld",
    "foo": { "mlink": "<hash>" }
}, getContext)
// whete getContext is a function that could make requests, like:
// getContext("/ipfs/aaaaa/ipld") -> schema

I'll try to summarize what we said on IRC @jbenet ?
We start from the following representation:
{ README.md: {mlink: <ipfs hash>}, dir: { file: { mlink: <ipfs hash> } } }

The problem is that we have to know which keys to expand to type URI (when we declare LD context) and which keys are filenames and must no be expanded. JSON-LD can declare values using @container: @index but that works for one level only, and the next level must contains keys that can be expanded.
We could imagine this structure in JSON-LD, but it has an extra level of indirection:
{
@context: {
  links: { @container: @index }
}
"links": {
  // this is an index container
  "mlink": {"mlink": "hash"}, // this is a file entry
  "README.md": {"mlink": "hash"},
  "some-dir": {
    // this is a node, not an index container
    "links": {
      "test.c": {"mlink": "hash"} } }}}

If we don't want to have the level of indirection, we depart from JSON-LD (which is not a problem if we can convert back to JSON-LD). The other problem is that we have a collision problem between filenames and @... directives. The proposed solution is to escape the @ character in keys:
{ dir: {<EMAIL_ADDRESS>{ @context: <ipfs context>, mlink: <ipfs hash> } } }

When compacted it would lead to:
{ dir/\@context: { @context: <ipfs context>, mlink: <ipfs hash> } }

This is nice because this is almost JSON-LD object already.
With directives stripped for JSON compatibility, it would transform to:
{ dir: { @context: { mlink: <ipfs hash> } } }

(@context is a file name)
Some extracts:

so you cannot do: { "@context": { "@container": "@index" }, "foo": { ... }, "bar": { ... } } ??
In that form: no. if you transmit the context out of band, probably yes
and foo/bar must contain LD objects, not maps. ie. the foo and bar objects cannot have arbitrary keys
foo and bar objects are the extra level of indirection.

about escaping:

btw, one nice thing is that a json object having {"foo": {"bar":1}, "foo/bar":2} is not "broken". i.e. it can still work in ipfs, because traversal is deterministic (i.e. lexicographically ordered. so "path/to/obj/foo/bar" -> 1. (( whether "path/to/obj/foo/bar" -> 2 is a good idea is left for another day.

@jbenet you're ok with this ?
For me the escaping is a very good solution, the only question left is about flattening. When you transform {foo: {quux: {} }, bar: { baz: {} } } into {foo/quux: {}, bar/baz: {}}.
How do you know when to stop down the hierarchy ?
Does it stops when it finds a non escaped @context (or other directive) ?
We're very close to compatibility with JSON (via escaping) and JSON-LD (via directives and flattening operation).

thanks @mildred! all lgtm.

How do you know when to stop down the hierarchy ?
Does it stops when it finds a non escaped @context (or other directive) ?

good questions. not sure yet.
not sure whether we should store flattened by default-- user may want to preserve data structure. but we can flatten for our purposes.

A fresh day, fresh ideas:

use @container: @multiindex to tell that we have a multiple level map
the map stops when we got an object containing any @ directive. Or we could require each level to contain the @container directive to signify it extends itself to multi levels.
perhaps we should tell either in the context or the JSON itself what is the separator for flattening
when converting to JSON-LD, we flatten the map and present it as JSON-LD using @container: @index instead
if we want to add attributes to the root node (the one containing the multiindex) we could perhaps add a @attrs directive containing them, we could also specify how to interpret the index appearing on top.

A unixfs entry as encoded by IPLD would appear like this:
{
  @context: <ipfs hash for root context>
  @container: "@multiindex", // could be in context
  @attrs: {
    // These are te unixfs directory attributes
    type: "unixfsdir",
    mode: 0775,
    // This tells how the multiindex should be interpreted (could be in context)
    @index: "files"
  },
  "some-dir": {
<EMAIL_ADDRESS>{
      // we already have a root context to specify the mlink
      // perhaps we want to include the context here to be more specific
      // ((recognize this is always the same IPFS hash)
      @context: <context for mlink>,
      mlink: <ipfs hash of file entry>,
      // we can also extend JSON-LD to add the index  key<EMAIL_ADDRESS>      // to the LD data model as the filename attribute (possibly be in context)
      @indexkey: "filename"
    }
  }

With this, IPFS makes some simple assumptions. Easy flattening algorithm. The meaning of the mlink keys is always the same because the context for the mlink is always the same hash. IPFS wouldn't need to interpret the context, just compare it with the known hash of mlink.
We can also, after a translation step feed this to any JSON-LD consumer that would be quite happy to understand this in a LD context
We can also strop the @ directives and give it unescaped to any JSON consumer
@jbenet does it still correspond to what you want. How do you stop recursion, @container directive for each level, or any @ directive for the leaf nodes ? Also, I'm available (CEST tz) on IRC, just ping me.


Option to configure enableExternalNameService

Recently, enableExternalNameService is default being set to false to mitigate https://github.com/kubernetes/kubernetes/issues/103675. This is creating a breaking change for Knative. It would be nice to be able to use the operator which we use in our Knative serving e2e tests to override this for now, until we move forward with one of the paths below.
For more context https://github.com/knative/serving/issues/11821.

I think this is fair, we should do this.


State Migration Tool

Blocked by #123
### Tasks
- [ ] https://github.com/celo-org/optimism/issues/7
- [ ] https://github.com/celo-org/optimism/issues/65
- [ ] https://github.com/celo-org/optimism/issues/9
- [ ] https://github.com/celo-org/optimism/issues/36
- [ ] https://github.com/celo-org/celo-blockchain-planning/issues/181
- [ ] https://github.com/celo-org/optimism/issues/134

End of weekly commitment check-in: @palango can you provide a status update?

PR is ready and waiting for review: https://github.com/celo-org/optimism/pull/138

End of weekly commitment check-in: @palango what's the current ETA? Is #141 the last thing left & in progress?

#141 is now solved in https://github.com/celo-org/op-geth/pull/149
But new issues keep coming up, so it's not done yet.

All necessary tasks for state migration are done. Improvements are tracked in https://github.com/celo-org/optimism/issues/169


Read only users can't access pages with unapproved drafts

We recently installed the plugin and have the hide_drafts_for_viewers option enabled. When our read only users accesses a page that has a draft waiting for approval, rather than getting the last draft their browser gives them an error page stating that they were redirected too many times. What could be the cause of this?

We also have it set so that you have to be logged in as one of our users to view any pages, and if the start page is one of the pages where the redirect issue occurs, the browser displays the too many redirects error before the login screen shows up.

This should be fixed now. Please let me know if it works for you.

Yes it is working now. Thanks for getting back so fast. Any idea when this version will be uploaded to the Extension manager so I know when to switch back to using that? Or do I just need to watch for a new "last updated" date on the extension page?

I will update the plugin version in dokuwiki.org today evening. After that it should be visible in Extension manager.

Wow, that's perfect! Thanks for all the work that you do! This extension is exactly what we needed for our workflow, its comforting to know that if bugs are found it has a very active developer, at least for the moment.


Issue with details of module being deleted

I deleted modules: Connectivity Proxy and Transparent Proxy.
Despite view of the modules didn't exist any more, module were presented on the Modules list with Ready state.
When clicked on a module, I was lead to the empty page (screen below) and couldn't come back (need to reopen the busola)
For some time when I clicked on those modules to display a details, right panel opened but the message was saying module doesnt exist

Remedy
UI must be more resilient, not to be broken for the time of module deletion. 404 page may be displayed but it must have a link back to the module list.
+We need to check why module's UI was deleted but the module still presented as Ready on the list (is it something wrong with module deletion process or some caching in UI?)

The prolonged Ready state after deletion is not on our side, this is the information we get from the yaml. Our part is to handle the case when there is no resource details.

We need to disable onClick for details view, when module is also in Error state, because when I'm adding the eventing for example, for couple seconds/minutes it is in Error state and extension for details is not available.


Update to react-bootstrap 0.28.1 and widen react nav

Moved away from deprecated navbar components and props
Removed mixin from FCCNavItem
Updated stylesheet so the .container react-bootstrap adds doesn't impact nav positioning

Closes #4571
Closes #4585

Nice work @ltegman, as always!
Happy Coding!


Feature request: JSON Feed

It would be nice to have JSON Feed implemented in Hugo.

The JSON Feed format is a pragmatic syndication format, like RSS and Atom, but with one big difference: it’s JSON instead of XML.
For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.
Our hope is that, because of the lightness of JSON and simplicity of the JSON Feed format, developers will be more attracted to developing for the open web.

Oops, its a duplicate of #3487
Please close!

@pjctech why would this be nice, exactly?


Use @Inject for injecting ioc stuff into facets

Would be better than to call woko.ioc.getComponent() all the time...

+1

We already have woko.ioc.WokoInject that works on "setter methods". We just need to make it work on fields, so that instead of :
@FacetKey(name="foo", profileId="all")
class FooAll extends BaseResolutionFacet {

    private MailService mailService

    @WokoInject(MailService.KEY)
    void injectMs(MailService ms) {
        mailService = ms
    }

    @Override
    Resolution getResolution(ActionBeanContext abc) {
        new StreamingResolution('text/plain', "mail=$mailService")
    }
}

one can also write :
@FacetKey(name="foo", profileId="all")
class FooAll extends BaseResolutionFacet {

    @WokoInject(MailService.KEY)
    MailService mailService

    @Override
    Resolution getResolution(ActionBeanContext abc) {
        new StreamingResolution('text/plain', "mail=$mailService")
    }

}

Note that this opens up the mailService to binding, but you should use @StrictBinding everywhere anyway so...

We may also want to leave the value blank, and let the Types be used, if possible.

Requires a new method in woko.ioc.WokoIocContainer I think. One that allows to get the list of all registered components.


[Bug]: Router randomly stops showing views on navigation

Describe the bug 🐞
Routing stops showing views on the second (and further) navigation to the same view instance.
Reproduction repository
https://github.com/Leon99/AvaRxUI.git
Expected behavior
Routing shows views on the second (and further) navigation to the same view instance.
Screenshots 🖼

IDE
Rider Windows
Operating system
Windows 11
ReactiveUI Version
19.4.1
Additional information ℹ
Same code works fine using Avalonia's built-in routing.
Same code works fine if view instances are not reused (registered as not a singleton).
Same code works fine when using Splat service locator.

As discussed in #1028 this is a known Avalonia bug. Follow up there.

Thanks for the investigation @ChrisPulman!
I'm confused though - if https://github.com/AvaloniaUI/Avalonia/issues/12333 is the root cause, then how come the issue is not reproduced when using TransitioningContentControl directly, and also not reproduced when only Splat is used for IoC?

...with that said, setting PageTransition="{x:Null}" fixes the issue.

I was able to reproduce the error when using any of the DI's the page transition animation is the root of the issue, there's an open bug in Avalonia which matches the exact issue being observed. If you set the transition to null this will disable the transition and therefore not fail.


Controller stuff

Throughout the library, I'd like to replace all "non-value" enum variants (the "Nones", "Invalids", etc.) with Option::None.
Constants such as SDL_CONTROLLER_AXIS_INVALID exist to communicate errors to the caller, yet they aren't polymorphic to the other variants; Axis::Invalid must be ignored or treated differently from the other axes because it doesn't indicate a "real" axis. This is basically a rewording of the "null" problem.
-> SdlResult<T> is changed to -> T for functions that cannot fail.
As well as with the "renderer" pull request, I'm attempting to convert i32 (int) values into u32 values wherever negative values don't make sense (such as width, height, counts and indices). This is explained further in src/sdl2/macros.rs.

Great! Cheers


Add Credit debt calculator Extension

I want to add  the credit payment history and credit card details .
So anyone track their details history.

i basically want to make this typo::

Kindly update for the pull request. Otherwise I will close this @jayraj175coder


setting getter-only property

Version
5.0.0-beta.1
Steps to reproduce

Build latest next branch or use beta build from jsdeliver
Try dragging the datazoom component (test/dataZoom-feature.html some tests seem to fail but some work such as /test/dataZoom-axes.html)

What is expected?
Datazoom component to zoom the data axis
What is actually happening?
data not zoomed and exception
Uncaught TypeError: setting getter-only property "length"
    copyValue file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:7110
    animateToShallow file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:7202
    animateToShallow file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:7140
    animateTo file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:7020
    animateTo file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:6921
    animateOrSetProps file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:18077
    updateProps file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:18096
    _doUpdateAnimation file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:37177
    render file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:36746
    progress file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:23268
    _doProgress file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:21655
    perform file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:21627
    renderSeries file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28885
    eachSeries file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:19858
    each file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:379
    eachSeries file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:19855
    renderSeries file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28874
    render file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28851
    update file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28527
    doDispatchAction file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28740
    dispatchAction file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:28338
    _dispatchZoomAction file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:73663
    exec file:///C:/Users/Kieran/incubator-echarts/dist/echarts.js:23290
echarts.js:7110:7

This seems to be fixed in the latest commits, turns out I didn't have the dev env set up correctly so it was using the already commited dist/echarts.js


Rewrite Chapter 10 to use sessions from the start

This PR rewrite the start of Chapter 10.
Sessions: The server now implements sessions using a token cookie from the very beginning. This avoids presenting readers with insecure code (which they might remember better than later fixes!) and also helps us avoid focusing too much on the server.
One cookie: The browser now implements a single cookie per origin. Crazy, but it simplifies the code quite a bit, doesn't hurt anything else in the chapter, and makes the lack of support for multiple Set-Cookie headers less bad.

This chapter is factually incorrect: for cookies, the "scheme" is not used in the same-origin policy. If we build a nice cookie-parameter system we can throw in the "secure" attribute.

Actually this still isn't right, because for cookies SOP doesn't include ports if they're not explicitly stated—otherwise HTTP and HTTPS generally wouldn't match. Ugh.


Crash on EPG cache update

I have full logging on, there's not stack/exception...
Suggestions?
[2021-09-02 16:20:12,983] NOOB - Updating iptvorg EPG cache.
Killed
systematically.

Theoretically, it should return an empty programguide
https://github.com/fHDHR/fHDHR_plugin_origin_IPTVorg/blob/main/epg/__init__.py#L14

can you set the config [logging]level=debug?

can you set the config [logging]level=debug?
It is set to debug, that's why I was surprised to not see any message at all.

Odd, you should get a reason for a crash

https://github.com/fHDHR/fHDHR/pull/184
Try this core update, and see if that helps


How to read astropy tables with asdftool?

Given an astropy table, how do I use asdftool to read the tabular data (i.e., under the key data).
from astropy.table import Table

table = Table({"colname": list(range(10))})
table.write("data.asdf", format="asdf")

I thought it be asdftool info --show-value data.asdf, but the flag makes no difference.

This seems to just be the limitation and intention of info and that asdftool is missing AsdfFile::tree output.
To be more of a useful printout tool, maybe something add asdftool search and asdftool tree to the commands such that we can do something like
$ asdftool search "data" data.asdf | asdftool tree
{ 'asdf_library': { 'author': 'The ASDF Developers',
                    'homepage': 'http://github.com/asdf-format/asdf',
                    'name': 'asdf',
                    'version': '2.8.3'},
  'history': { 'extensions': [ { 'extension_class': 'asdf.extension.BuiltinExtension',
                                 'software': { 'name': 'asdf',
                                               'version': '2.8.3'}},
                               { 'extension_class': 'astropy.io.misc.asdf.extension.AstropyExtension',
                                 'software': { 'name': 'astropy',
                                               'version': '4.3.1'}}]},
  'data': <Table length=10>
colname
 int64
-------
      0
      1
      2
      3
      4
      5
      6
      7
      8
      9}

It wasn't the intent of info to look at the data, whether image or table. It does suggest that a utility like that would be useful (probably separate ones for simple arrays and tables). Info was more intended to examine the structure of the file (meta data and the location within the tree of any data). So it is a good suggestion that such utilities would be useful, mainly for the shell command line.

Sorry, I did not write clearly. I completely agree info is for a structural preview of the tree.
Anyways, this is something I can take a stab at contributing (checking if @drdavella @mdboom have considered this).


SCSS compiler error

[x] bug
[ ] feature request
[ ] enhancement

Expected behavior

./src/styles.scsscode
@import "~clarity-icons/src/clarity-icons";
@import "~clarity-ui/src/main";

0.8.8 can be compiled successfully
Actual behavior

ERROR in ./~/css-loader?{"sourceMap":false,"importLoaders":1}!./~/postcss-loader!./~/sass-loader!./src/styles.scss
Module build failed:
undefined
^
      File to import not found or unreadable: ../utils/form-variables.
Parent style sheet: D:/src/xx/node_modules/clarity-ui/src/forms/_forms.clarity.scss
      in D:\src\xx\node_modules\clarity-ui\src\forms\_forms.clarity.scss (line 4, column 1)
 @ ./src/styles.scss 4:14-195
 @ multi ./src/styles.scss

Reproduction of behavior

Environment details

Angular version: 2.4.9

Clarity version: 0.8.9

OS and version: windows10

Browser: all

Hi @tossp: We have already added a fix for this which will be published next week in 0.8.10: https://github.com/vmware/clarity/pull/558
This bug was introduced in 0.8.9 so the earlier version (0.8.8) should work fine too.

@adityarb88 Thank you very much for your important information


Should not display pattern without passcode

Should not display pattern without passcode entry
https://github.com/bithyve/bitcointribe/assets/107177634/653706cb-4ec1-4999-8424-adf6eb771467

Verified this issue on Tribe app v 2.2.2(594)


Added a custom favicon.

Added custom favicon to assets/favicon.
Added relevant HTML for cross-browser compatibility.
Closes Issue #3 .

@nidhishs Looks great thanks! If you want, you can also update the Contributors and open another PR for that


support drain timeout

Tell us about your request
Sometimes nodes get stuck when a pod could not be drained, so we have to alert ourselves and then manually kill it, which is not ideal.
It would be nice to set an optional drainTimeout so we can ensure nodes always die after x hours/days.
Are you currently working around this issue?
Helper pod that kills pods on stuck nodes so they finish draining.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

What should happen after the drainTimeout has elapsed? A pod not terminating may be by design, e.g. it's waiting for an IO operation with a long timeout.

it should force-delete the pod
the flag will definitely need "this has xyz downsides" warning
but dealing with empty nodes hanging around is also an overhead and especially in staging clusters we want to make sure cost is under control when things go wrong

Related to #2391

@grosser, can you elaborate a bit on what can cause the node to get stuck? Do you have do-not-evict pods, or broken PDBs?. We're currently scoping some work in this area and looking to see what makes sense here.

broken pdbs
we as cluster admins need to roll the clusters, but some other teams left their apps in a bad state
in production that would mean we have to reach out to them or at least check that their app is not critical, but in staging we'd like to just ignore it

I wonder if we should just hardcode something like 10 minutes if eviction is returning a 500. Do you need to configure this value?

I wonder if we should just hardcode something like 10 minutes if eviction is returning a 500. Do you need to configure this value?

I don't think it's good to hardcode any timeout since by default the system should be safe for the workloads and fail the cluster rollout instead.
The opt-in could be either a timeout or true/false ... but I think timeout makes the most sense.

What would you set it to?

nothing in production and 10-15m in staging

The other wrinkle here is that we won't attempt (iirc, or perhaps it's just deprioritized) to deprovision a node that has a blocked PDB, so we'll need handling for both disruption and termination flows.

Would you want to treat a 500 (misconfigured) differently than a 429 (pdb unfulfilled)?

I'd treat them the same, either way:
production: the owning team needs to check it out before we can proceed
staging: go fix your app 🤷

Great feedback, thank you!

Related / extra credit: manage machine drains through a custom resource, similar to how the node maintenance operator does it. This could include reporting progress via .status

How does https://kubernetes.io/blog/2023/01/06/unhealthy-pod-eviction-policy-for-pdbs/ fit into your use-case? Does it solve it? It's behind a Beta feature gate in 1.27.

it solves it for completely unhealthy applications and should not have a big impact for regular operations
it however does not solve the situation when only part of a pdb is unhealthy (for example new pods are unhealthy and old pods are healthy)

@jonathan-innis does anyone start to work on this issue yet?

Is it possible to expose and implement a timeout in the finalizer? If nothing is set (default) then it never times out but if it exist it should be easy enough for the finalizer to simply annotation the machine/ node with drain started with and if that now - annotation > timeout -> force kill the node/ machine?

I found out recently that graceful deletion for custom resources (as in CRDs) doesn't really seem to be a thing.
If that's right then we'd need an improvement to Kubernetes itself, and then could indeed gracefully delete the Machine, using the future-dated removal to signal the drain timeout.

Can you provide some details? I think you are correct however shouldn't finalizer on CRD (machine) work equally as well? Trying to understand what specific API you need from K8s

Graceful deletion has an associated time; finalizers don't have any time stored in the API.

Ah ya that's unfortunate

I think to upstream that change would take a while. I wonder if there is a mid to short term solution? I believe we might just fork Karpenter core and add the ability into the finalizer that picks up the timeout from the config map and some kind of annotation on the machine to mark it with time deletion attempt

We had talked about including a timeout here that would infer from the NodePool or node itself to control the drain/eviction logic and forcefully evict once a drain/termination has reached the timeout. We'd essentially need to mock the graceful deletion ourselves, as I don't think there's any graceful deletion for nodes. We had a PR https://github.com/aws/karpenter-core/pull/466 that explored this, but haven't had the time to get to it.


Remove extraneous/incorrect ValidatesRunner classification from examples unit tests

Some cleanup.
The ValidatesRunner tests are meant to be compliance tests for the Beam model. There are unit tests of the examples so they don't belong in that category. They are not included in the ValidatesRunner suites anyhow, because we do not scan these test jars.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

assign reviewers

assign set of reviewers

R: @Abacn


Change DB API to find constant key IDs.

This changes the BuildEngine <-> DB interaction to rely on first getting a
unique (interned, effectively) ID for all keys.

That change allows us to then change the BuildEngine-level result to store
dependencies in terms of key IDs, instead of expanded rules. This results in
dramatically reduced memory usage, but also since this matches the underlying
database schema it allows for much more efficient loading of the result
dependencies.

In particular, this eliminates several joins from the database
implementation.

There is potentially more we could do here to eliminate the ancillary key
table entirely and simply make the results themselves serve as the canonical
identifier for a rule, but that requires a little more work.

This is good for a 35% speedup on null builds of large build graphs.

rdar://problem/32139612 Change RuleResult to store key IDs

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test