Dependency Cycle reported when an ApplicationListener depends on a Feign client

Describe the bug
I have an application where a bean that implements ApplicationListener<ApplicationContextEvent> depends on a feign client. The application fails to start because Spring thinks there is a dependency cycle. Debugging shows that this is due to AbstractApplicationContext.refresh() being called during creation of the feign client bean.
spring-cloud version is Hoxton.SR1, spring-boot version is 2.2.4.RELEASE.
Sample
Here's a simple application that shows the problem. I created a Kotlin app using Spring Initalizr with only OpenFeign selected as a dependency, then changed the DemoApplication.kt as follows:
package com.example.demo

import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.cloud.openfeign.EnableFeignClients
import org.springframework.cloud.openfeign.FeignClient
import org.springframework.context.ApplicationListener
import org.springframework.context.annotation.Configuration
import org.springframework.context.event.ApplicationContextEvent
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RequestMethod

@SpringBootApplication
@EnableFeignClients
class DemoApplication

fun main(args: Array<String>) {
    runApplication<DemoApplication>(*args)
}

@FeignClient(name = "myFeignClient")
interface MyFeignClient {
    @RequestMapping(method = [RequestMethod.POST])
    fun hello(): String
}

@Configuration
class MyApplicationListener(private val myFeignClient: MyFeignClient) : ApplicationListener<ApplicationContextEvent> {
    override fun onApplicationEvent(event: ApplicationContextEvent) {
        println("ApplicationEvent: $event")
    }
}

The application fails to start, saying:
2020-02-03 15:21:38.365  WARN 81421 --- [           main] s.c.a.AnnotationConfigApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'myApplicationListener': Requested bean is currently in creation: Is there an unresolvable circular reference?
2020-02-03 15:22:02.452  WARN 81421 --- [           main] s.c.a.AnnotationConfigApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'myApplicationListener' defined in file [.../target/classes/com/example/demo/MyApplicationListener.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.example.demo.MyFeignClient': FactoryBean threw exception on object creation; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'myApplicationListener': Requested bean is currently in creation: Is there an unresolvable circular reference?
2020-02-03 15:22:02.464  INFO 81421 --- [           main] ConditionEvaluationReportLoggingListener :

Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2020-02-03 15:22:02.480 ERROR 81421 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  myApplicationListener defined in file [.../target/classes/com/example/demo/MyApplicationListener.class]
↑     ↓
|  com.example.demo.MyFeignClient
└─────┘

Inject an ObjectProvider<MyFeignClient>

Ah, I see this is in the docs of the latest Snapshot but not yet in the GA docs. Thanks!
I had tried adding the @Lazy annotation to the client, but that didn't work. Now I see that adding @Lazy to the injection point works as well - i guess it does more or less the same as using an ObjectProvider but hides it behind a proxy.

Why does ObjectProvider resolve this issue?

Why does ObjectProvider resolve this issue?

It breaks up the dependency cycle, you could say. Using ObjectProvider or the Lazy annotation will give Spring a chance to initialize the object only when it‘s used, not when it’s injected.

it looks like feign client depends on ApplicationListerners, but I cannot find that declaration


Saving credentials to external storage failed

all permissions granted, works in android 9 and below.

Hi @RobertoLayna,
We'd be glad to assist.
Are you requesting that the user to grant access to WRITE_EXTERNAL_STORAGE via a permission dialog, before calling Pushy.register()?
// Check whether the user has granted us the READ/WRITE_EXTERNAL_STORAGE permissions
if (ContextCompat.checkSelfPermission(getApplicationContext(), Manifest.permission.WRITE_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) {
    // Request both READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE so that the
    // Pushy SDK will be able to persist the device token in the external storage
    ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.WRITE_EXTERNAL_STORAGE}, 0);
}

If the user doesn't consent, the SDK won't be able to write to the external storage.

I require them before calling the register,
I have tested it in versions prior to android 10 and it works without any problem ( checking the path where they are saved )

Android 10
Moto g(7) power

Hi @RobertoLayna,
Can you please let us know your app's targertSdkVersion defined in app/build.gradle?

targetSdkVersion 30
implementation 'me.pushy:sdk:1.0.56'
Now tested on:

Huawei P20
Android 11


Properly parsing 'Wednesday'

Hi,
I've been using this great library for a while but I'm running into an issue with parsing relative dates like "wednesday". This returns the past week's wednesday (if today is Sunday (3/4/18), it'll return (2/28/18). I know there's a setting for PREFER_DATES_FROM: future but the problem with that is if I have that turned on, wednesday parses correctly to 03/07/18. However,  if we then try to parse 03/07/18 it'll become 03-07-2118 ( notice it becomes 2118 rather than 2018 due to the line here). What's the best solution to account for parsing both wednesday & 03/07/18 correctly?
I guess the real bug is with PREFER_DATES_FROM: future parsing 09/07/18 as 09-07-2118. That doesn't seem like the right behavior to just add 100 years if the future flag is set since the closest future date is 09-07-2018 not 09-07-2118

Hello!
Thank you for voicing that problem, but at the moment I can't reproduce it:
In:  dateparser.parse("09/07/18", settings={"PREFER_DATES_FROM": "future"})
Out: datetime.datetime(2018, 9, 7, 0, 0)

In:  dateparser.parse("02/07/18", settings={"PREFER_DATES_FROM": "future"})
Out: datetime.datetime(2118, 2, 7, 0, 0)

So, it looks like the behaviour is correct. If the date is in the past, we skip to the nearest future date that fits. If it's in the future, we leave it like that.
If your results differ, could you post more details about your system configuration?

@asadurski The issue here is in finding the nearest future.
The nearest future is "year +1" and not "year +100"
https://github.com/scrapinghub/dateparser/issues/468

Closing due to a lack of feedback from the original author after indicating that we cannot reproduce the issue. @trideeprath’s feedback can be handled at #468 instead.


Failures in trades at 00:00:00hs

There is some problems  at time 00hs when a trend is running. This has happened only in few occasions. I attached videos and workspace.
Video 1: at the end of the trade the ROI changes twice.
Video 2: the trade ends abruptly
Archive.zip
.

@EduRemix to check this I would need to know if this is still happening at the latest version provided, and if yes, a workspace that is being used. Also instructions on which task to execute and at which date and time period this happens.

No answer, closing this issue.


Add new geometry class for triangulated meshes

Is your feature request related to a problem? Please describe.
Point clouds maintain the notion of absolute coordinates but do not allow for the computation of geodesics, on the other hand graphs take adjacency matrices as inputs, regardless of the original basis/orientation in 3D space.
Describe the solution you'd like
An implementation of the form mesh.Mesh(coordinates, faces) which generates a geometry object with the default cost defined as the geodesic distance (heat kernel for example) over the mesh.
Describe alternatives you've considered
As for now the best way is to instantiate a point cloud and pipe in a custom cost matrix computed with a package like tvb-gdist.
Additional context
This is specific to dimension 3 yet could benefit to a lot of OT applications (shape alignment, computational anatomy, etc...)

We already have 2 graph-based geometries, namely Geodesic and Graph; would close this for now since from what I think you're suggesting is just to create a graph from a 2D/3D mesh, which should be fairly easy.


Change How We Store Access Tokens in the Database.

Problem Definition

In the beginning, we only had OPAC (UUID) tokens. When we're issuing a new token, we just stored the token string in ACCESS_TOKEN column of our database and we used the same token string as the cache key.
Then came JWT access tokens, which the token string is quite large compared to UUID token. Therefore, storing it directly in the database caused problems. As a solution, we used the JTI claim value as a representation of the token and stored this in the ACCESS_TOKEN column.
Since we have two different behaviors regards to tokens, now we had to decide what type of token came to the server during token validation calls (such as introspect) in order to extract the value to match with the DB. In order to identify whether a token is JWT or not, we looked for periods (.) in the coming token string.
This broke when a customer came with his own token issuer, which issues compressed JWT tokens. These tokens had the right amount of periods but they were not parsable as usual JWT tokens.
As a solution, we implemented a chaining logic, where we try all available token issuers one by one until a parsable issuer is found. If one parser throws an exception, we continue the loop and checks with the next token issuer.
This also broke when another customer came with his own JWT token issuer which issued usual JWT tokens that did not contain a JTI value. Our own JWTTokenIssuer can parse these tokens and therefore we pick it and continue the flow. When we try to extract the JTI value to lookup, we get nothing and flow breaks.

Proposed Solution

We think we're facing these regression issues because we didn't go with a proper design in the first place. The original issue was that we cannot store JWT token string directly in the DB as it is too large.
As a solution, we propose to hash the token and store it in a new column we'd like to call LOOKUP_HASH. Either it's a UUID or JWT or something else, we use the same hash function to get the hash and store it in this column.
Whenever a token validation call comes, we do the same again. Hash the token string and lookup. Cache keys should also be this same token hash value.
When issuing a new token, we can store the real token in the ACCESS_TOKEN column if it's a UUID token, which is used to send the same token if the same request came again. In JWT case, we can store anything, since it doesn't serve any purpose.

PS. We already have an ACCESS_TOKEN_HASH column, which is not search-friendly since it is a JSON value. I hope we can do something about that too.

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


⚠ Bofrost.lu has degraded performance

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

HTTP code: 200
Response time: 1687 ms

Resolved: Bofrost.lu performance has improved in 6f7f73d after 11 minutes.


Gravity Refactor

This PR is the tracking branch for the gravity refactor. Core goals of the refactor:

One codepath and an interface for all events relayed from ethereum to cosmos
One codepath and an interface for all transactions going from cosmos to ethereum
One codepath and an interface for all signatures over transaction from cosmos to ethereum
Ensure that use of orchestrator key and validator key are interchangeable
Rename a number of concepts to more closely match what the abstractions are doing (i.e. Confirm -> EthereumSignature)

would highly recommend using converting the ETH addresses bytes through common.HexToAddress(tokenContract).Bytes() instead of []byte(tokenContract) as this is much less error prone. We ran into issues on our end where tokenContractA was proper hex checksum format but tokenContractB was not (e.g. it was lower cased) and the module was treating them differently, so we refactored everything to use the native geth common.Address type and the .Bytes() method accordingly.

@albertchon replaced to use common.HexToAddress(tokenContract).Bytes(), at least where I found it


Hide X-axis

Is there a way to hide a charts x-axis?

There's not an official way, but I'd look into the library option.


UV wrap configuration

Tremendous work! Best paper in 2021. The output from Densepose is different from the one in the example. How is the uv 0-1 mapped to RGB? What configuration do you use when using Densepose? Also, is it really uv map or vertex map on the SMPL model I should be using? The uv map from this repo and the one genereated from Densepose by myself  look different.
original

Yours

Mine

Thanks for the message. different weight of densepose has different results.
The visualization you show is IUV the visualization we have in this example is VUI. so you may just want to change the order of channels. We use densepose, not SMPL.

Hi Yasamin,
Which color map do you use? DensePose in detectron uses [cv::COLORMAP_PARULA] and swapping the channels doesn't make it consistent with what you have. Any idea?

You can refer to this issue:https://github.com/facebookresearch/detectron2/issues/4554, I used his method to solve the problem.


Collective balance checks for virtual cards

User story
With the introduction of virtual cards, we need to see how we implement controls to avoid situations where the card is charged when the collective balance is below the transaction amount.
We identified this situation through Mautic experience, as charges went through the main collective page as a default rather than the associated event page.

Best solution for this problem
Balance checks to be in place, similar to the practice around routine expenses raised.

++ I have mentioned this over in the sprint planning discussion: https://github.com/opencollective/opencollective/discussions/4405#discussioncomment-938205

@znarf this is already in place for stripe cards, right? To check that the Collective doesn't go into negative from card charges.

@alanna for Stripe cards yes, Stripe is asking us if we want to approve the payment in real time and we're checking the balance. For Privacy cards, we're not doing this.

@znarf I thought all the Privacy cards were deactivated Jan 31? I think we should deactivate support for Privacy as soon as is practical, so we don't end up supporting that as a legacy system unnecessarily. Then we can close this issue too.

@znarf should we close this?

Privacy Cards can still be used internally (OC, OSC, OCF).
This feature was anyway not doable for Privacy and we're not supporting Privacy anymore for Collectives, we can close.


Move field types into separate module

Codecov Report

Merging #37 (1222c06) into master (750926f) will decrease coverage by 13.05%.
The diff coverage is 44.44%.

@@             Coverage Diff             @@
##           master      #37       +/-   ##
===========================================
- Coverage   76.90%   63.85%   -13.06%
===========================================
  Files          49       49
  Lines        4283     4283
  Branches      545      545
===========================================
- Hits         3294     2735      -559
- Misses        769     1361      +592
+ Partials      220      187       -33

Impacted Files
Coverage Δ

...n/kotlin/dev/evo/elasticmagic/doc/DateFieldType.kt
91.17% <ø> (ø)

...n/kotlin/dev/evo/elasticmagic/aggs/Aggregations.kt
48.38% <ø> (ø)

...nMain/kotlin/dev/evo/elasticmagic/doc/DocSource.kt
65.95% <ø> (-7.88%)
:arrow_down:

...onMain/kotlin/dev/evo/elasticmagic/doc/Document.kt
84.66% <ø> (-0.85%)
:arrow_down:

...tlin/dev/evo/elasticmagic/query/FieldOperations.kt
47.61% <ø> (-4.77%)
:arrow_down:

...ain/kotlin/dev/evo/elasticmagic/types/FieldType.kt
72.90% <44.44%> (ø)

...c/commonMain/kotlin/dev/evo/elasticmagic/Result.kt
0.00% <0.00%> (-100.00%)
:arrow_down:

.../evo/elasticmagic/compile/UpdateMappingCompiler.kt
0.00% <0.00%> (-96.67%)
:arrow_down:

...otlin/dev/evo/elasticmagic/compile/BulkCompiler.kt
0.00% <0.00%> (-92.43%)
:arrow_down:

...otlin/dev/evo/elasticmagic/ElasticsearchCluster.kt
0.87% <0.00%> (-89.48%)
:arrow_down:

... and 22 more

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 750926f...1222c06. Read the comment docs.


[python mode] better highlighting for and/or/not

Currently and/or/not in most themes look like normal text because cm-operator doesn't usually get special styling. This patch highlights them as keywords to make them stand out better.

Sounds good. Merged as 2e16ef6


Support for alias in Django record manager

Adds support for db alias in record manager.
Useful in case of multiple django applications in the same codebase.
Other usecase is migration of the eventstore using different alias
This is just a POC. Additional changes may be needed.

Closing this in favour of https://github.com/pyeventsourcing/eventsourcing-django which has this now, I think.
@vladimirnani if you want to keep this open, please just reopen and we can work on it okay :)


UX: should the Themes option in the About LeftNav be a link rather than a tab?

Right now, clicking the settings icon (or issuing about) gives a LeftNavSidecar with a Themes tab. Selecting that tab presents the themes table in the sidecar body.
Proposal
Change this to be a Link that issues the themes command in a Terminal.
Advantages

Tables in the sidecar have never looked great
Users can have an odd situation of seeing a themes table simultaneously in the Terminal and the Sidecar

no longer relevant

no longer relevant


Allow terminal environment variables to be unset via terminal.integrated.env.windows

Context: https://github.com/Microsoft/vscode/issues/35550
  "terminal.integrated.env.windows": {
    "LANG": null
  },

This follows the plan set forward for setting the env in the extension API too, see https://github.com/Microsoft/vscode/issues/20446#issuecomment-314267087 and https://github.com/Microsoft/vscode/pull/30352

@Tyriar I would do this. Could you recommend way to unset env

Hmm... looking further at this, I can see that there is this option:
// Controls whether locale variables are set at startup of the terminal, this defaults to true on OS X, false on other platforms.
"terminal.integrated.setLocaleVariables": false,
Looking at the code, I don't think that setting this to false does what the comment says. Setting this to false, as per the code, will simply fallback to setting the LANG env variable to en_US.UTF-8 which is probably not the intended behavior?
at this point, locale is undefined since the variable above is set to false
env['LANG'] = TerminalInstance._getLangEnvVariable(locale);
private static _getLangEnvVariable(locale?: string) {
const parts = locale ? locale.split('-') : [];
const n = parts.length;
if (n === 0) {
// Fallback to en_US to prevent possible encoding issues.
return 'en_US.UTF-8';
}
seems like maybe the code should be:
if (locale)
{
env['LANG'] = TerminalInstance._getLangEnvVariable(locale);
}
Just how I interpreted the code/comment :)

@Nazeehe nice catch, that is indeed a bug. I've reopened https://github.com/Microsoft/vscode/issues/35550 to fix that. This issue will remain open as it's a useful request still 😄

This is fixed, I've changed my mind on being able to unset $LANG though, the terminal.integrated.setLocaleVariables setting should be used instead.


Returns -1 at first EOF at Base64.DecodingInputStream

When InputStream that is used as source for Base64.DecodingInputStream returns -1 (aka EOF) at the first read, the Base64.DecodingInputStream.read returns 0 that broke contract for this method.
The root cause of the issue that eof flag doesn't checked after iterate.
Fixed it.

Thanks for the PR. Could you please file an issue that describes the issue, with a reproduction, so that we can refer to it in the PR?

@sjrd done and improved to code to support old scala


HADOOP-17822. fs.s3a.acl.default not working after S3A Audit feature

Fixes the regression caused by HADOOP-17511 by moving where the
cannedACL properties are inited -so guaranteeing that they are valid
before the RequestFactory is created.
Adds

A unit test in TestRequestFactory to verify the ACLs are set
on all file write operations
A new ITestS3ACannedACLs test which verifies that ACLs really
do get all the way through.

Testing: S3 london; full suite in progress with acls set in auth-keys.xml
Also verified via a "hadoop fs -touchz s3a://stevel-london/acl4" call
<property>
  <name>fs.s3a.acl.default</name>
  <value>LogDeliveryWrite</value>
</property>

then verify through AWS CLI
>  aws s3api get-object-acl --bucket stevel-london --key acl4
GRANTS  FULL_CONTROL
GRANTEE <owner>        CanonicalUser
GRANTS  WRITE
GRANTEE Group   http://acs.amazonaws.com/groups/s3/LogDelivery
GRANTS  READ_ACP
GRANTEE Group   http://acs.amazonaws.com/groups/s3/LogDelivery
OWNER   <owner>

@mukund-thakur @mehakmeet @bogthe

rebased onto a few patches behind on trunk, before the CSE support went in. that's triggering failures and I need to differentiate CSE-related regressions and anything from this PR

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  1s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m 26s

trunk passed

+1 :green_heart:
compile
0m 45s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 39s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 30s

trunk passed

+1 :green_heart:
mvnsite
0m 45s

trunk passed

+1 :green_heart:
javadoc
0m 26s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 35s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 10s

trunk passed

+1 :green_heart:
shadedclient
14m  1s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 40s

the patch passed

+1 :green_heart:
compile
0m 39s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
0m 39s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
0m 32s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 21s

the patch passed

+1 :green_heart:
mvnsite
0m 36s

the patch passed

+1 :green_heart:
javadoc
0m 17s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 27s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 14s

the patch passed

+1 :green_heart:
shadedclient
14m 28s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 10s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 34s

The patch does not generate ASF License warnings.

74m 12s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3249

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 12fff8484361 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 3ffb85eadf2dbf8f7ef52bf5b362be63e1dba247

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/1/testReport/

Max. process+thread count
691 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-aws U: hadoop-tools/hadoop-aws

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
17m 51s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
34m  4s

trunk passed

+1 :green_heart:
compile
0m 44s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 35s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 26s

trunk passed

+1 :green_heart:
mvnsite
0m 43s

trunk passed

+1 :green_heart:
javadoc
0m 21s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 28s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 12s

trunk passed

+1 :green_heart:
shadedclient
16m 58s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 36s

the patch passed

+1 :green_heart:
compile
0m 40s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
0m 40s

the patch passed

+1 :green_heart:
compile
0m 31s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
0m 31s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 19s

the patch passed

+1 :green_heart:
mvnsite
0m 35s

the patch passed

+1 :green_heart:
javadoc
0m 15s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 23s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 14s

the patch passed

+1 :green_heart:
shadedclient
16m 56s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 22s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 30s

The patch does not generate ASF License warnings.

98m 28s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3249

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 7dd55b86dde6 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1ed1e66ec1be4de01bbdb03004ef5ffddb857237

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/2/testReport/

Max. process+thread count
563 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-aws U: hadoop-tools/hadoop-aws

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

I've done a full test run with
<property>
  <name>fs.s3a.acl.default</name>
  <value>LogDeliveryWrite</value>
</property>

breaks all assumed role tests because the roles aren't being created with "s3:PutObjectAcl" permission. Fixing this and updating the docs as appropriate. Will need to update the assumed role I test with too

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  6s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
12m 26s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
22m 39s

trunk passed

+1 :green_heart:
compile
22m 57s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
19m 19s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
3m 47s

trunk passed

+1 :green_heart:
mvnsite
2m 22s

trunk passed

+1 :green_heart:
javadoc
1m 33s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
2m 17s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m 40s

trunk passed

+1 :green_heart:
shadedclient
17m 13s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 33s

the patch passed

+1 :green_heart:
compile
22m  1s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
22m  1s

the patch passed

+1 :green_heart:
compile
19m 24s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
19m 24s

the patch passed

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
3m 46s

the patch passed

+1 :green_heart:
mvnsite
2m 21s

the patch passed

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
1m 31s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
2m 17s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
4m  5s

the patch passed

+1 :green_heart:
shadedclient
17m 10s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
16m 58s

hadoop-common in the patch passed.

+1 :green_heart:
unit
2m 28s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 48s

The patch does not generate ASF License warnings.

206m 52s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3249

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell xml spotbugs checkstyle markdownlint

uname
Linux fff2241c118c 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 0af71d6570a12521c89e2c8d7359fd2c3cd81532

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/6/testReport/

Max. process+thread count
1952 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/6/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  2s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
12m 56s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
37m 55s

trunk passed

-1 :x:
compile
29m 18s
/branch-compile-root-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
root in trunk failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
compile
0m 40s
/branch-compile-root-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
root in trunk failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

-0 :warning:
checkstyle
0m 37s
/buildtool-branch-checkstyle-root.txt
The patch fails to run checkstyle in root

-1 :x:
mvnsite
0m 38s
/branch-mvnsite-hadoop-common-project_hadoop-common.txt
hadoop-common in trunk failed.

-1 :x:
mvnsite
0m 38s
/branch-mvnsite-hadoop-tools_hadoop-aws.txt
hadoop-aws in trunk failed.

-1 :x:
javadoc
0m 46s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-common in trunk failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
javadoc
0m 43s
/branch-javadoc-hadoop-tools_hadoop-aws-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-aws in trunk failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
javadoc
0m 39s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-common in trunk failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

-1 :x:
javadoc
0m 42s
/branch-javadoc-hadoop-tools_hadoop-aws-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-aws in trunk failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

-1 :x:
spotbugs
0m 40s
/branch-spotbugs-hadoop-common-project_hadoop-common.txt
hadoop-common in trunk failed.

-1 :x:
spotbugs
0m 40s
/branch-spotbugs-hadoop-tools_hadoop-aws.txt
hadoop-aws in trunk failed.

+1 :green_heart:
shadedclient
7m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 24s
/patch-mvninstall-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch failed.

-1 :x:
compile
18m  3s
/patch-compile-root-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
root in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
javac
18m  3s
/patch-compile-root-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
root in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

+1 :green_heart:
compile
24m 59s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
24m 59s
/results-compile-javac-root-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
root-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 1793 new + 0 unchanged - 0 fixed = 1793 total (was 0)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
3m 53s
/results-checkstyle-root.txt
root: The patch generated 5 new + 0 unchanged - 0 fixed = 5 total (was 0)

+1 :green_heart:
mvnsite
2m 21s

the patch passed

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

-1 :x:
javadoc
1m  0s
/results-javadoc-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-common-project_hadoop-common-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 99 new + 0 unchanged - 0 fixed = 99 total (was 0)

-1 :x:
javadoc
0m 38s
/results-javadoc-javadoc-hadoop-tools_hadoop-aws-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-aws-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 63 new + 0 unchanged - 0 fixed = 63 total (was 0)

+1 :green_heart:
spotbugs
4m  6s

the patch passed

+1 :green_heart:
shadedclient
17m 26s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m 17s

hadoop-common in the patch passed.

+1 :green_heart:
unit
2m 43s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 48s

The patch does not generate ASF License warnings.

189m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3249

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell xml spotbugs checkstyle markdownlint

uname
Linux b2e110c8740a 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / eb146aa585b91ca6715efa949f7f6ce004c53e93

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/7/testReport/

Max. process+thread count
3137 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3249/7/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

have I just broken everything?

It is not you, it is we! So did anything break? I ran re-ran the tests on a PR up to date with trunk and nothing suspicious broke.

ok. If it was a full breakage someone would have noticed, rolled back, re-opened, emailed me etc. It does happen from time to time.


TagGroups namespaces

It would be nice to add namespaces at the group level, like this:
tagGroups:
      - name: 'User'
        tags:
          - 'Entity'
          - 'Reports'
      - name: 'Common'
        tags:
          - 'Reports'

And in decorators:
@ApiTags('User.Reports')
// ... some user reports controller

@ApiTags('Common.Reports')
// ... some common reports controller

But render without dots, like:
User
> Reports

Common
> Reports

I have a related need where I want the same tag label to be rendered under different groups. Being able to assign an id/label to a tag would help.


[BUG]: failed to create pvc

An error installing a service that needs a persistent volume (for example, kafka).
kubectl describe pvc datadir-0-kafka-cp-kafka-0
Name:          datadir-0-kafka-cp-kafka-0
Namespace:     default
StorageClass:  local-path
Status:        Pending
Volume:
Labels:        app=cp-kafka
release=kafka
Annotations:   volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
volume.kubernetes.io/selected-node: aks-ledge
volume.kubernetes.io/storage-provisioner: rancher.io/local-path
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       kafka-cp-kafka-0
Events:
Type     Reason                Age                  From                                                                                Message

Normal   WaitForFirstConsumer  16m                  persistentvolume-controller                                                                         waiting for first consumer to be created before binding
Normal   Provisioning          3m33s (x5 over 16m)  rancher.io/local-path_local-path-provisioner-5c64749b78-6rgk6_e4266c3e-96e3-43d4-b19a-df339bc138be  External provisioner is provisioning volume for claim "default/datadir-0-kafka-cp-kafka-0"
Warning  ProvisioningFailed    93s (x5 over 14m)    rancher.io/local-path_local-path-provisioner-5c64749b78-6rgk6_e4266c3e-96e3-43d4-b19a-df339bc138be  failed to provision volume with StorageClass "local-path": failed to create volume pvc-6a2dba06-afff-4526-830e-6d450377906b: create process timeout after 120 seconds
Normal   ExternalProvisioning  90s (x62 over 16m)   persistentvolume-controller                                                                         waiting for a volume to be created, either by external provisioner "rancher.io/local-path" or manually created by system administrator

local-path storage class does exist.
kubectl get storageclass
NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  42m
Environment (please complete the following information):

Hi @sokunna,
Thanks for reaching out.  Although the local-path storage class is present by default, there are some components missing that will impact the creation of a PV. Could you please follow Local Path Provisioner on Azure Kubernetes Service Edge and redeploy the local-path storage class and try again?
Thanks,
Francisco

@fcabrera23  Yes this seems to be fixed by deleting the old storage class and creating a new one per instruction. Is there plan to have the default one worked out of the box? Thanks.

Hi @sokunna,
Local path storage requires some containers (local-path, busybox) that Microsoft does not maintain. Hence, we do not plan to include these as part of our VHDX soon.
Thanks,
Francisco


Godot closes if you resize a window

Godot version
3.5-rc5, 3.4.2 stable, 3.4.4 stable
System information
Windows 10, NVidia 3080, driver 516.59
Issue description
Godot closes if you resize a window
https://user-images.githubusercontent.com/108496359/176793163-87b283f9-e580-4da2-943e-ae3aa0cd3f2e.mp4
Steps to reproduce
Just launch Godot and resize a window with the mouse
Minimal reproduction project
No response

Duplicate of https://github.com/godotengine/godot/issues/24702.


First commit: add navbar_badge and add main example

This PR implements the badges and dot feature and integrate them to the navbar_router, with minimal codebase changes.
Based on badges packagae of flutter.
Features:

Customize badges according to badges packagae, including size, color, position, animation,.. and put them into NavbarItem to set up initial badges.

NavbarItem(Icons.home_outlined, 'Home',
        backgroundColor: colors[0],
        selectedIcon: const Icon(
          Icons.home,
          size: 26,
        ),
        // --- it's here ----
        badge: NavbarBadge(
          badgeText: "11",
          showBadge: true,
        ))

Next, you can update your badges by using NavbarNotifier.
NavbarNotifier.setBadges(int index, NavbarBadge badge) // new badges
Flexibly show or hide badges on demand
NavbarNotifier.makeBadgeVisible(int index, bool visible)
or set the default behaviour of hiding on tap:
-- Setting the attributes in NavbarRouter when you setup your navbar:
final bool hideBadgeOnPageChanged;
-- Setting it manually anywhere:
NavbarNotifier.hideBadgeOnPageChanged = true;

Demo video
Showing random badges/dots on button click (taking from main.dart in example folder)
https://github.com/maheshmnj/navbar_router/assets/74720131/0e0f68d6-fe31-4976-81ad-27fea8a46118

Support all types of navbar available (I think so).

List which issues are fixed by this PR. You must list at least one issue.
Reference: #36 and #30
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is [test-exempt].
[x] All existing and new tests are passing using flutter test

P.s: This is my first-time fork so if anything's gone wrong please tell me! Thank you, have a good day! @maheshmnj

Awesome! @bebaoboy I am currently traveling will review it soon.

Meanwhile, can you please add some tests regarding this change? You can refer to existing tests in test folder for your reference. Let me know if you need any help.

I'll make some tests when I'm available soon, as I'm still working on my college projects (using the navbar too)
Pretty awesome work!

Sure thing take your time, Good luck with your school project. I won't be able to review it for another two days. I need to prepare for my conference too and be back be on this PR soon.

Yeah so i made some enhancement and added some badge tests. They're all passed (together with current tests) for all types of navigation bar.

Also, the badges look a bit weird on the default UI for web (default). And umm, this is because I don't know how to customize the background of the navigation bar on web, as of now. Below is the picture, taken from my app:

Again, take a look on this PR when you're free 😊 Thank you.

Another thing I want to ask is whether we want to wrap badges over user's child widget of NavbarItem.

I think having a badge parameter in NavbarItem class would be the right approach.

Perhaps we should also take into consideration that parameters in NavbarItems can be updated in runtime.
Otherwise we wrill run into a this issue #38, This is yet to be addressed.

@bebaoboy I reviewed your PR its kind of lagging on the web when switching to profile tab, need to investigate further. If you run the app on the web it freezes on switching tabs and the app is no longer usable.

Hello, How do I run the app on the web like you said to test it?

Strange, I saw severe lag issue last night and now I can't reproduce it. It seems to work pretty smooth. I think we are good on the performance part as of now. I am reviewing the code will share the feedback soon.

@bebaoboy I have made some comments can you please review and incorporate them?
Thanks

@bebaoboy I have made some comments can you please review and incorporate them?
Thanks

Help I don't see them, where are your comments ... Please tell me, thank you

Oops I did not submit the review, Apologies you should see them now.

Rest looks good to me, Once this is merged I will update the documentation here https://github.com/maheshmnj/docs/tree/main/docs/navbar_router
If you would like you are welcome to contribute to the documentation.

Great work @bebaoboy. Thank you for contribution!
This feature will be available in the next release.


new Worker() warning in minified version of jsPDF

I'm using version 2.3.0 in an Angular project (version 9). When I'm creating a build for my application, I'm getting this warning:
WARNING in new Worker() will only be bundled if passed a String.
@ ./node_modules/jspdf/dist/jspdf.es.min.js 51:0-50 189:1249-1250 222:4938-4939 328:1268-1269 328:1460-1461

I didn't have this warning when I used jsPDF version 2.2.0.

Cannot reproduce. JsPDF does not create any workers on its own. Please share a small project that reproduces the issue.

Cannot reproduce. JsPDF does not create any workers on its own. Please share a small project that reproduces the issue.


Have flux already installed on the cluster

What would you like to be added?
Having flux already installed in the cluster it simplifies and make it consistent with other labs like argocd
Use helm to install
https://github.com/fluxcd-community/helm-charts
Why is this needed?
The terraform setup of the cluster would need to be updated to install the helm chart of flux.
Investigate if bootstrap is need it or it can also be done as part of terraform setup.
If its simple do this changes we want to do it now, if becomes too complex then will wait for the new architecture of workshop that each lab/module would have their own setup/start and end scripts.
cc @niallthomson

Assign to me, please!

With the restructure we've moved away from pre-installing components like this, so I'm closing this issue.


Support using cookie as a form of identification

Rather than only supporting the Authorization header as a way to identify a user, it would be nice if we could use the client provider to retrieve the user through a session cookie.

We can already do this thanks to WithCustomTokenExtractor


Small fixes to the explore docs

In the distributed_portals_with_elixir.livemd notebook Kino is used before it is installed causing an error, I've added the install cell before its usage.
Updated a broken link to the "Introduction to Kino" notebook in chat_app.livemd

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


Draft harvesting operations workflow documentation

Draft started here: https://docs.google.com/document/d/1grOS3ifpi03Kj3CMd4sGtXbqf_ylkTqrNbkT6ZyRl6Q/edit

Completed preliminary harvesting documentation to populate candidate index / for cutover


Enabling error tracking makes the app stuck at start

Describe what happened
When we enable error tracking in DdSdkReactNativeConfiguration init, our application stuck on loading.
Steps to reproduce the issue:
npm install<EMAIL_ADDRESS>npx react-native run-android
adb logcat or look at the console using debugger
Describe what you expected:
Being able to track errors in our app without any blocking load.

  - DatadogSDK (1.5.1):
    - Kronos (~> 4.1)
  - DatadogSDKBridge (0.2.0):
    - DatadogSDK (~> 1.5.1)
  - dd-sdk-reactnative (1.0.0-alpha3):
    - DatadogSDKBridge (~> 0.2.0)
    - React
  - Kronos (4.2.1)
  - React (0.62.2)

- A copy of your `package.json` file

{
  "dependencies": {
    [...]
    "@react-navigation/bottom-tabs": "^5.11.7",
    "@react-navigation/native": "^5.9.2",
    "@react-navigation/stack": "^5.14.2",
    "dd-sdk-reactnative": "1.0.0-alpha3",
    "react": "16.11.0",
    "react-native": "0.62.2",
  },
  "engines": {
    "node": "12"
  }
}

Hello @VincentCATILLON! Can you please give us more details on that issue so that we can reproduce it? Does it happen on emulator or on real device? Do you experience the same with our sample app? Can you provide the output of your logcat it is has any entries related to the issue?

Hi @0xnm
It only happened on Android device using alpha3 (don't know if it happens on emulator only or on both emulated and physical devices).
The JS code is:
    DatadogService.config = new DdSdkReactNativeConfiguration(
      CONFIG.clientToken,
      env,
      CONFIG.applicationId,
      true,
      true,
      true // This param at true, makes the app stuck at start
    );

But it seems to boot without any issue since the android bridge dependency bumped from 1.8.0-alpha1 to 0.2.0 👍
Thanks for your time

Hello @VincentCATILLON,
I'm not able to reproduce the issue using the config provided by you. I would recommend to do the following steps:
a) Wait for our next SDK release which will happen soon, where we re-worked some native dependency handling.
b) Try to update React & React Native version to the version recommended by our SDK and check if the issue is still there.
c) Check if issue still happens if you build and run our example app in your environment.
d) Check if you have long task reported in Datadog dashboard.
Logcat output above doesn't show any issue unfortunately.

Hello @VincentCATILLON. I'm closing this issue due to inactivity, but please feel free to open it again if you still experience it.


compile node_modules with bare minimum too

as a general exclude on node_modules doesnt seem to be a good idea, we compile them too (but with a bare minimum of features). the idea is inspired by CRA https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/config/webpack.config.prod.js#L313-L353
Description
separate babel loaders for SRC and NODE_MODULES
Changes/Tasks

[x] Changed code

Motivation and Context
to be able to use external ESM
Types of changes

[ ] Refactoring/add tests (refactoring or adding test which isn't a fix or add a feature)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My changes have tests around them

@tannerlinsley another attempt of #769 maybe you can give it a try with some external ESM packages too?! it seems to work here (https://github.com/uber/react-map-gl/pull/599 is an outstanding issue, but probably not related)

Sounds good. I tested this and it seems to work with the libraries I had in question so far.


Add S3 fixture using minio

Close #49

What's the best way to launch this for circleci? Minio doesn't have an apt package currently that I can see. I could wget the binary from their site but that's not usually a great way to do stuff

Should I add a SERVER_FIXTURES_MINIO env var for the binary path?

cc @eeaston

I added a CONFIG.minio_bin for it. Can I get some feedback on the approach?

Tests pass for me once I work around #44 by changing the line to host = '<IP_ADDRESS>'

teardown isn't killing minios correctly - I'll need to address this before this gets merged

Hi @Daenyth ! Thanks for raising this, just going through it now.

I'll try to address your feedback in the coming week.

Regarding the circleci build - if there's no official .deb or anyone that's packaged it using their own update-site, I'm happy for you to wget the binary into /usr/local/bin or wherever.

Sorry for the long delay, hadn't found time to work on this. I addressed the feedback; let me know if you'd like further changes.

@eeaston take a look, i think all your requests have been met

It's all fine - sorry again for the big delay myself. Merging, and thanks for your contribution!


command-line-args always empty

Are *command-line-args* supposed to be accessible?
When I put:
;;; with-args.clj
(println *command-line-args*)

In with-args.clj, and run:
$ ferret -i file-name.clj -c

[+] Compiling
[+] Formatting Code
[+] Building Binary
[+] Compiler: g++
[+] Options:
-std=c++11
[+] Include Path:
[+] Library Path:
[+] Link:
[+] Done

And do:
$ ./a.out 1 2 3
I get:

()

Is there a compiler config I'm missing?

It is supposed to be accessible, it mimics Clojure's command-line-args. I've fixed the issue added tests. Latest build should work as intended.

I couldn't find *command-line-args* in the docs (my fault I'm sure), so I spent a few hours trying to reverse-engineer how args work by looking through the generated c souce! :laughing:

Hi,
Its not you apperantly I forgot to mention it in the docs. I've added it under I/O section. On a related note do you have any suggestions to add to the docs that I missed in order to make better sense of the generated code.
Best,

Thank you very much Nakkaya. Ferret is incredible, I'm using it more and more. I'll certainly drop issues and PRs as and when I find gaps in the docs.
First one that came to mind as surprising: The difference between macro-expansion time (ie, compile time) and runtime. I spent a few hours wondering why strings were behaving oddly!


No module named pytest

Installation instructions on fresh ubuntu instance and installing pytest gives "No module named pytest" when you try to run tests as in the example:
python3.6 -m pytest ethereum/tests/test_opcodes.py

ok ... after quite a lot of digging found sudo apt-get install python3-pytest fixes the problem "No module named pytest"...will submit a pr to update the readme once i run though things and find anything else missing

After countless attempts on Debian, MacOS etc, finally got this working on Unbuntu 17.04:
Clean Ubuntu 17.04 install
sudo apt-get update
sudo apt-get install python3.6
apt install python3-pip
sudo pip3 install ethereum
sudo apt-get install libssl-dev build-essential automake pkg-config libtool libffi-dev libgmp-dev
sudo pip3 install ethereum


ReaderFactory.Open does not check for SevenZipArchive

Thus when using ReaderFactory.Open I get an error of

Cannot determine compressed stream type.   You need random file access to properly extract data.   You have to use ArchiveFactory.

Yeah, I figured it out, but had to read the source code. Are there docs?
Sent from my iPhone

On Nov 21, 2019, at 2:25 PM, Adam Hathcock<EMAIL_ADDRESS>wrote:

7Zip isn’t supported as a Reader. 7Zip the format sucks because you can’t stream it. You need random file access to properly extract data. You have to use ArchiveFactory.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Linked from the readme: https://github.com/adamhathcock/sharpcompress/blob/master/FORMATS.md


Unable to see other players on the map when they don't have this mod

On the map, other players who don't have the mod installed were able to see me and another player who had installed the mod, but they were still able to see us.

This seems to apply to anyone - if you have the mod installed, you will randomly not see others on the map even when their map visibility installed. Seems to occasionally fix itself for one person but not the other on re-login.
Others who don't have the mod installed can still see everyone whether they have the mod installed or not.


Update sbt to 1.4.3

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

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

labels: library-update, semver-patch

Coverage remained the same at 63.966% when pulling dbf788713916e13468c10ade0b9d24a81d53dae9 on scala-steward:update/sbt-1.4.3 into 933218eff81678de98b86ef433e8b0082f78d6c6 on evolution-gaming:master.


Could use a better name

FastDMA covers a lot of space.
Something like chisel-fastgraphicsdma ?

Names are hard but we are happy about the name. Its written in Chisel, sure, but you don't call linux kernel "ckernel" just because its in C. Also its a general DMA, not just for graphics. Lets leave the name as is for now...


THRIFT-4476: Typecasting problem on double list items, emitting doubles with high precision (for Java, C++, Python, JS and Erlang)

All commits have been squashed into one
see the related issue: https://issues.apache.org/jira/browse/THRIFT-4476

Thanks for the squash.  We'll get this merged.


Allow jax.pure_callback to infer result_shape_dtypes

I was wondering if it would be possible to allow jax.pure_callback to infer result_shape_dtypes by calling the specified function once at trace time and using the result's treedef. This saves users the trouble of having to manually specify result_shape_dtypes. Possible implementation:
import jax
import numpy as np

def to_numpy(tree):
    return jax.tree_map(lambda x: np.zeros(x.shape, x.dtype), tree)

def pure_callback_auto(f, *args, **kwargs):
    tree = f(*to_numpy(args), **to_numpy(kwargs))
    return jax.pure_callback(f, tree, *args, **kwargs)

@jakevdp Would you like me to create a PR for this?

I'm interested to hear what @sharadmv thinks of the idea

@jakevdp Now that pure_callback and io_callback are switching from NumPy arrays to JAX arrays, this seems even easier to do: Just call jax.eval_shape(callback, *args, **kwargs). Is my understanding correct?

@carlosgmartin I think that would work in the simplest cases where the callback functions are implemented in terms of JAX operations. But I think this will be a rare case: why do a callback if your operations are entirely expressible in terms of JAX operations? More frequently the callback will likely call out to some other non-JAX API, for which eval_shape will fail.

Good point. I wonder if there's a way to maintain the zero-flop property (for JAX operations) while computing with non-JAX operations. There's still the possibility that result_shape_dtypes depends on the value of the JAX input, but that seems like a rarer situation.

Some of the cases I had in mind were things like
import jax
from timeit import default_timer
jax.eval_shape(default_timer)

ShapeDtypeStruct(shape=(), dtype=float32)

I've deleted my previous comment, since I was confused.
I think jax.eval_shape can work even if the function is not entirely expressible in terms of JAX operations. For example, consider timeit.default_timer:
import timeit
import jax

print(jax.eval_shape(timeit.default_timer))
# ShapeDtypeStruct(shape=(), dtype=float32)

This allows one to do things like the following:
import timeit
import jax

def io_callback_auto(callback, *args, **kwargs):
    shape = jax.eval_shape(callback, *args, **kwargs)
    return jax.experimental.io_callback(callback, shape, *args, **kwargs)

def f(h, _):
    return h, io_callback_auto(timeit.default_timer)

_, xs = jax.lax.scan(f, None, None, length=10**6)

print(xs)
# [881338.3 881338.3 881338.3 ... 881340.  881340.  881340. ]

Could you give a concrete example where this wouldn't work, if you had one in mind?

I don’t disagree that some useful callbacks are compatible with eval_shape, I’m just pointing out that it’s likely the majority will not be. It’s not clear to me that it’s helpful to have a default that will fail in the majority of cases.


Update github action on building dependency ml-commons

Is your feature request related to a problem? Please describe.
Currently, since ml-commons artifact hasn't been published to public Maven, we add it into github action to build ml-commons. After ml-commons artifact is on public Maven, remove this github action and grab it from public Maven.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

#407

ml-commons has been published to remote maven https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/


Fix incorrect documentation URLs when using rubocop --show-docs-url

Added DocumentationBaseURL for rubocop --show-docs-url [COP1,COP2,...] command to work correctly for rubocop-minitest cops.
Before
$ bundle exec rubocop --show-docs-url Minitest/AssertEmpty
https://docs.rubocop.org/rubocop/cops_minitest.html#minitestassertempty

After
$ bundle exec rubocop --show-docs-url Minitest/AssertEmpty
https://docs.rubocop.org/rubocop-minitest/cops_minitest.html#minitestassertempty

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[ ] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Is the following issue resolved?
https://github.com/rubocop/rubocop-rails/pull/756#issuecomment-1225030048

Thanks!


SectionDemux sample code

Considering the extraction of a table such as the NIT in your example, you should use a ts::SectionDemux. This is a class which does all section demuxing, table reconstruction and notifies the application when a new complete table is available. By accumulating raw TS packets as you are doing, you will have to manually recreate the complicated stuff in ts::SectionDemux. TSDuck classes are all designed to hide the complexity and provide a high-level and simple-to-use interface to applications or plugins.

Where Can I find a sample code for using SectionDemux like you describe? I trying to use TSDuck as a library in my project to extract some tables from a TS file.
Originally posted by @fabricioizumi in https://github.com/tsduck/tsduck/issues/317#issuecomment-861611623

Hi @fabricioizumi
In short, you need to develop a C++ class which implements TableHandlerInterface, use an instance of SectionDemux with an instance of your class as table handler, sets the PID's to demux, pass all TS packets to the demux. Whenever a new version of a table is detected on one of the demuxed PID's, your class implementing TableHandlerInterface will be called with that table.
TSDuck is the largest pool of sample code. SectionDemux is used everywhere. I would suggest to start with:

src/tsplugins/tsplugin_nitscan.cpp
src/libtsduck/dtv/broadcast/tsTSScanner.h & .cpp

Ok, thanks for your answer. I study the code in tsTSScanner.cpp and I have success in implement a class based in TableHandleInterface. Thanks!


Make playbook into two pieces

GitHub Issue: https://github.com/Islandora/documentation/issues/2166
What does this Pull Request do?
This is a bit of a naive first attempt, probably needs a way to continue the original full build steps. Or if you wanted to use this to build a remote machine you'd need to run both sides.
For discussion.
What's new?
Adds a new environment variable to check for called ISLANDORA_BUILD_BASE if it is "true" then the playbook will build a ubuntu/focal64 box with Java, Tomcat 9, Apache, MySQL/Postgres, ActiveMQ, Solr and Cantaloupe installed.
There is some configuration I didn't move, for instance Apache is configured to use the eventual Drupal folder as its DocumentRoot. But as there is nothing there you get a error page.

Does this change require documentation to be updated? Yes it will, if adopted
Does this change add any new dependencies? no
Does this change require any other modifications to be made to the repository
(i.e. Regeneration activity, etc.)? no
Could this change impact execution of existing code? 🤷

How should this be tested?

Pull down this PR in a directory.
Build the base box.> ISLANDORA_BUILD_BASE=true vagrant up

This should import the ubuntu/focal64 box, that will be one of the first steps it executes. Once it is complete (without errors 🤞 )
Package the box.> vagrant package --output islandora_base

This shuts down the VM and exports it to the file islandora_base in this directory.

Now build a VM using the base box.> vagrant up

This should show it is importing the islandora_base box.

That's it, you can now destroy and rebuild the VM using this base image as many times as you need.
Interested parties
Tag (@ mention) interested parties or, if unsure, @Islandora-Devops/committers especially @rosiel

🥳 @whikloj I was scared when I saw how quickly the base box built. But this is awesome!
Base box built in 6m:28s
It took a bit to export, but I didn't time it.
The rest of it built in 5m:40s. I saw no errors and the front page loads
Wizardry!! 😀  What do we need to make this 🚀 ?

do we still want a full build option in one run?

Two steps is fine. I imagine running them could be done "at once" by chaining the commands, like this?
ISLANDORA_BUILD_BASE=true vagrant up; ISLANDORA_BUILD_BASE=false vagrant provision;

can you login to the box?

vagrant ssh worked just fine. is there anything else I need to test?

As this is not the flagship distribution method for Islandora, I'm not sure how careful we need to be.

Agreed.

We could make this separate branch so the original dev remains pure but that tends to lead to one or the other branch being more valued.

We have already created a 1.0.0 release, so I think that binds us to some degree of semantic version-y responsibility. Therefore I think this should be 2.0.0 or something. I know it's not even managed by Composer, but cutting a release where the non-back-compatible changes happen would let anyone who's running this and encounters problems know where they can go up to without altering how they interface with the playbook.
But branches? the playbook is so minimally maintained, and I can't imagine us maintaining two branches, let's do this all on the dev branch.

we could push a copy of islandora_base up to Hashicorp (sp?) if we wanted

I think we can wait, maybe come back to it in a few months. The base box is really fast to build, and i don't think we have the people/tools to maintain another external snapshot thing right now.

I am fine with your answers. I hadn't thought about just provisioning over top. I am fine with just adding a new tagged version, we might want to add a last 1.x.x tag to include the last bits (not sure anyone is using the tags) and then add a 2.0.0 tag to the commit that adds this change.

Can you add islandora_base to .gitignore? (if not no worries i can make another PR)

😢 I just ran into a problem that i think was caused by this split (but I'm not sure). After building the site on top of the base box, going to http://localhost:8000/admin/config/search/search-api/server/default_solr_server showed me a big red drupal warning banner error: "You are using an incompatible solr schema. Please follow the instructions in the README.md file for setting up Solr."

I don't know what to look for/at. The indexing worked fine: I went to http://localhost:8983/solr/#/, and did a query, and the results showed i had indexed two nodes and all their values.
But my View (I was using the default that came with the starter site, solr_search_content) returns 0 values, always.

Argh, okay. Let me look there is some futzing we do with the Solr stuff but I thought it was working.

That did it. Awesome stuff!


Nonsense login mechanism

Hi there,
I've spent over 2 hours on this and so far there is no clear solution.
I've pulled microsoft/iotedgedev from docker and followed https://github.com/Azure/iotedgedev (step 3) > iotedgedev init which as you can imagine requires me to authenticate.
So, I came here and I read "If the CLI can open your default browser, it will do so and load a sign-in page." which is not applicable in my case simply because the container doesn't run gui. So i figured let's try "az login -u myAzurePortalUsername", entered my password and it tells me "Get Token request returned http error: 400 and server response: {"error":"invalid_grant","error_description":"AADSTS50034: The user account does not exist in the MY_DIRECTORY directory."
I've been spinning in circles for something as basic as cli login.
Please help

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

ID: d884a3fe-07cf-e518-085d-602425fe2480
Version Independent ID: 1636994b-e193-74e2-9936-a07e43913326
Content: Run Azure CLI in a Docker Container
Content Source: docs-ref-conceptual/run-azure-cli-docker.md
Product: azure
GitHub Login: @sptramer
Microsoft Alias: sttramer

The recommendation could be to use this approach: https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest#sign-in-with-a-service-principal

@DoychinDoychev If you will be using interactive logins, simply use az login. This will present you with a token that you can use to log in with via a website, and supports using Microsoft accounts and other accounts with 2FA:
az login

If you are intending to automate a process using the docker container, please follow @mathieu-benoit's advice to set up a service principal. See the Create an Azure service principal with the Azure CLI documentation, or use the portal.


generated xml is not stable

See https://mailarchive.ietf.org/arch/msg/tools-discuss/yRqq-psSVnB-qoNbICFvzZQDmIo.
While attributes and unordered-element order doesn't matter to XML parsers, it matters a lot to text differencing engines.
The output should be stable (repeated fetches should return identical bits, not seemingly randomly reordered ones).

Transferred and acknowledged.
https://github.com/ietf-ribose/bibxml-service/issues/234 will address this issue.

We can canonicalize returned XML, but I’d like to learn more about the new use case being described.
For example, if there is XML diffing being done, isn’t it the responsibility of the differ to ensure all sources being diffed are canonicalized using the same method, rather than relying on API returning canonicalized XML and hoping it’s canonicalized with the same set of options?

Thanks! Can we have a sample to see how the canonicalized content looks?

While attributes and unordered-element order doesn't matter to XML parsers, it matters a lot to text differencing engines.

Text differencing engines should really not be relied upon for structured data content, but I recognise that in certain conditions, e.g. git, it is unavoidable.

Text differencing engines should really not be relied upon for structured data content, but I recognise that in certain conditions, e.g. git, it is unavoidable.

Well, currently our diffs with xml2rfc are very large since we pretty-print XML while xml2rfc tools outputs un-indented lines. Canonicalization ignores indentation, so every indented line is a difference.
It’s just another illustration that a diffing layer shouldn’t trust service to return a normal form and do extra mangling, going beyond the c14n spec, on its own to ensure both representations are truly as equivalent as possible.

It’s just another illustration that a diffing layer shouldn’t trust service to return a normal form and do extra mangling

I agree. A comparison can only work if the canonicalisation is run on both comparands.

It’s just another illustration that a diffing layer shouldn’t trust service to return a normal form and do extra mangling

I agree. A comparison can only work if the canonicalisation is run on both comparands.

Yes, it can ensure it runs the same canonicalization algorithm with the same parameters, and do any extra normalization beyond XML c14n spec if required.

The service canonicalizes XML now, and the order of elements should be consistent (more details: https://github.com/ietf-ribose/bibxml-service/issues/239#issuecomment-1193069048)


Takeover crowd2 plugin

Description
I want to continue maintaining the crowd2 plugin (@integer,@theit,@KostyaSha)  We're using the plugin at our company and I would like to merge the PRs and release a new version to fix same minor bugs
Permissions pull request checklist
Always

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

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] All newly added users have logged in to Artifactory at least once

Normally these sorts of discussions happen on the developers' mailing list rather than in a PR, especially when the plugin isn't listed as up-for-adoption, but what do you say, @KostyaSha?

Feel free to deal with ancient acegi shit!


appx releases on releases tag

I agree, maybe we/you could publich the appx of the app so users can install it without having to build it if they want the new version :)

@stmoy there was a new release. any chance that we'll see a release here too?

@stmoy I agree, adding the appx to the repo does not make a lot whole of sense. However we could upload an appx to the GitHub Releases as a form of "Insider Preview". But this would be rather a caveat and I don't think this would be necessary.

I made a similar issue on the Calculator repo and made points there

Terminal and winget do this. Would love to see a new release as the app is pretty outdated now.

This is still on my radar, but no updates yet. There's a few "infrastructure" related things that are on the list (including fixing the CI builds, building appx's, etc.) but it's been difficult to carve out the time to get it done 😅   Fortunately, the team has grown a little bit, so I'm hopeful that @kat-y will be able to help out here.

I agree that this is a good idea but not a top priority focus right now. I'll leave this issue open to make sure we don't forget about this suggestion :)


Low textures

Textures only work on low, anything else causes textures to break

how does it break exactly? can you show a screenshot?
additionally, if you have any texture packs, please try to disable them, it could be their fault.

how does it break exactly? can you show a screenshot?
additionally, if you have any texture packs, please try to disable them, it could be their fault.

Screenshot is shown on low textures. They jumble up on anything else even when i disable texture packs.

i mean show a screenshot of how it looks on medium/high, where it is broken.
and preferrably disable textureldr and make sure there is no Resources/dankmeme.globed2 folder in your game installation

i mean show a screenshot of how it looks on medium/high, where it is broken.
and preferrably disable textureldr and make sure there is no Resources/dankmeme.globed2 folder in your game installation

On high. I dont know what texture LDR is and there is no Resources/dankmeme.globed2 in my folder

High with no texture pack

Do you have the "DarkMode V4" mod installed? That mod messes with textures as well, and every Globed update could cause this to happen if you have that mod.

stale, closing


Windows 7 x86_64 emulation VM won't boot with different display devices

Describe the issue
My Windows 7 VM (emulated x86_64) won't boot with either virtio-gpu-(gl)-pci or virtio-ramfb-(gl).
virtio-gpu-(gl)-pci doesn't work at all. The display of the VM stays empty (seems to be expected, as no Win 7 support).
virtio-ramfb-(gl) hangs at the BIOS screen. I can only boot the VM with virtio-vga-(gl), which is quiet laggy.
I'm using the ANGLE (Metal) option.
I previously used the virtio-ramfb-gl device with Windows7 x86_64 in v4.0.9 which worked fine as far as I remember.
Configuration

UTM Version: 4.1.5
macOS Version: macOS 13.1
Mac Chip: M1 Pro

No I meant the virtio-ramfb-gl device, copied the wrong line in my post. At least that was the saved setting in the VM configuration, however I haven't started this VM in a long time. So no guarantee this worked 100%.
I'm just experimenting with the new 4.1.5 release and different settings. These are not issues that are critically for me.

Okay please double check because my recollection is that only virtio-vga works. But other vga cards also work and QXL is preferred on older Windows.

I'll check it tomorrow, need to load a backup.
However the QXL devices are unusable for me. It crashes the VM very frequent. Any way I can create a log for you?

Version 4.0.9 also doesn't boot with virtio-ram-fb. I can't test it with V3, since I don't have the VMs for that Version.
But it seems like that was a configuration issue on my side. I close this issue now.


4.0.0-alpha.9 not compatible with https://github.com/STARRY-S/zip/tags  0.2.1

What version of the package or command are you using?
my go.mod
        github.com/mholt/archiver/v4 v4.0.0-alpha.9
	github.com/STARRY-S/zip v0.2.1 // indirect

What are you trying to do?
go build ./cmd/ -o test
What steps did you take?
main.go
import (
	"os"
  	"github.com/mholt/archiver/v4"
)

func main() {
  a := &archiver.CompressedArchive{Archival: archiver.Tar{}}
  reader := os.Open("file.tar")
  if err := z.Extract(ctx, reader, nil, func(ctx context.Context, file archiver.File) error {
     return nil
  })
}

What did you expect to happen, and what actually happened instead?
Successful compilation
What actually happens
1.156 /root/go/pkg/mod/github.com/mholt/archiver/v4@v4.0.0-alpha.9/zip.go:311:16: zu.AppendHeaderAt undefined (type *"github.com/STARRY-S/zip".Updater has no field or method AppendHeaderAt)

How do you think this should be fixed?
I pope it could be easy to fix.

I'm not sure I follow. Our go.mod uses v0.1.0 of STARRY-S/zip:
https://github.com/mholt/archiver/blob/08f240f2d5a7db209cf5f1066eb60fa7eaafb065/go.mod#L18
So I do not see why v0.2.1 is expected to succeed. :thinking:

Looking at this again, I first read it as a bug report (because it uses the bug report template), but I wonder if you're actually asking for a feature request (support a new version of a dependency).
There is no bug here, but there is a request for something new.
Do you want to try https://github.com/mholt/archiver/commit/c932b5626be192c13e6bd822cfffa548cc3bfef5 (or latest on master) to see if that fixes it for you?

thanks you, will wait next release

Probably will be archiving this (heh) so as not to break existing users.


Customize RestGrid toolbar

This was for an old ticket - original goal was to simply allow RestGrid's extraToolbarItems prop to take an array or function.
I've also included the ability to customize the top right toolbar buttons with an additional prop. I recently worked on an app in which those buttons needed to be excluded.
I don't really like two separate toolbar props on RestGrid, but it does have the benefit of backwards compatibility.

Not crazy about the lack of symmetry here in the API with the additional change to add rightItems.
Would prefer we do nothing with regard to that.  In the future, we could provide a way to override the entire toolbar (including the actions) by creating a tBar property that would default to the current toolbar, but could be nulled out, or replaced entirely.


test

test

Coverage remained the same at 95.833% when pulling 1968bab1f37605ad1c113205445575b94853318c on gandhi23:master into a1ae7761d9d462ea8dd11872b7c529b37924e3a9 on openwisp:master.

Coverage remained the same at 95.833% when pulling e05dca9794e7bb8839d1e8b147b0447d8cd8130e on gandhi23:master into a1ae7761d9d462ea8dd11872b7c529b37924e3a9 on openwisp:master.


why the inference need to take so much time, one image need more 1 minute?

Indeed, the inference time of our autoregressive model is long compared to GAN-based or VAE-based models. The majority of the time is spend iteratively running the structure generator for 32x32 times. Please refer to the Supplementary Material for details on Inference Time.


riscv: Introduce T-Head extensions relevant to E serie

Adds xtheadba, xtheadbb, xtheadbs, xtheadcmo, xthead, xtheadcondmov, xtheadfmv, xtheadint, xtheadmac, xtheadmemidx, and xtheadsync.
GCC can take those options already, but it doesnt do anything at this moment as there is no implementation
These extensions are available on T-Head E907, and some as well on T-Head E906. These instructions are relevant for  devices like Bouffalolab BL616, Allwinner V853, Artin D133...

Hi, it doesn't do anything with gcc 13 either, there is still no implementation of those extensions in mainline/riscv gcc at all beside the extension names input.
LLVM/clang does support them fully, I believe they share target_riscv.cmake so that also gives it the support as well.

Hi, it doesn't do anything with gcc 13 either, there is still no implementation of those extensions in mainline/riscv gcc at all beside the extension names input.
LLVM/clang does support them fully, I believe they share target_riscv.cmake so that also gives it the support as well.

I get that.
My main concern is that even though the GCC 12.2.0 that Zephyr SDK uses can "accept" (i.e. it doesn't error out when they are passed) these extensions in the march cmdline argument, we're still essentially providing it extensions that it doesn't even mention in it's source code. This could give a wrong impression to the next person working on adding a new SoC, and selecting these Kconfig options without knowing that they are essentially unsupported by the GCC version shipped with Zephyr SDK.
But I guess that falls more into the "Toolchain Integration" area of maintenance, so @tejlmand or @stephanosio would have to chime in here.

But I guess that falls more into the "Toolchain Integration" area of maintenance, so @tejlmand or @stephanosio would have to chime in here.

The question is: does Binutils support these extensions? (i.e. can the assembler assemble the instructions from these extensions?)
If yes, then I do not think we need to do anything special here since -march flag does not imply GCC actively emitting all the instructions from the specified extensions -- it just needs to be able to recognise and assemble the instructions from the specified extensions in inline assembly.
If no, then we should emit a warning.

they are essentially unsupported by the GCC version shipped with Zephyr SDK.

Ah sorry, yes, but currently it does have the extensions listed in 13 but still does nothing with them as mentioned, so it's just inline with the current support status, even on 12. The difference is likely that on 13 you dont have to specify the version to avoid a error.

The question is: does Binutils support these extensions? (i.e. can the assembler assemble the instructions from these extensions?)

If you mean does it take 'th.icache.iall' in __asm__, no it does not, had to use .insn and direct CSR numbers for bl616 that requires xtheadcmo to work.

Hi @VynDragon ,
Could you point out how are you using this in your current branch? This could help to make people understand your needs.

Hello!

Could you point out how are you using this in your current branch? This could help to make people understand your needs.

It is not possible to use yet (due to gcc not supporting it fully, only the extension names, on GCC 14 for example this results in taking in the xtheadcmo in the riscv string, but using the instructions in a asm section results in unknown keywords, this is only available in LLVM atm, https://github.com/search?q=repo%3Agcc-mirror%2Fgcc+XTHEADCMO&type=code ), it is why I haven't tried to unstale this PR.
Current code uses pre-assembled .insn asm instructions.
I will unstale this once GCC supports those instructions.


nested buildSrc and included buildSrc builds build paths don't respect the buildSrc root project name

I expect the build path of buildSrc builds in which the root project name was changed to be updated accordingly.
Expected Behavior
build path should respect root project name for all buildSrc builds.
Current Behavior
build path seems hard-coded and to not respect the root project name.
Context
N/A
Steps to Reproduce (for bugs)
See composite-with-buildSrc-builds.zip
It's a build with

a buildSrc renamed 'rootBuildSrc', with a nested buildSrc named 'nested'
an included build named 'included', with a buildSrc renamed 'includedBuildSrc', with a nested buildSrc named 'nested'

Output is
./gradlew build --console=plain
> Task :buildSrc:buildSrc:compileJava NO-SOURCE
> Task :buildSrc:buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:buildSrc:processResources NO-SOURCE
> Task :buildSrc:buildSrc:classes UP-TO-DATE
> Task :buildSrc:buildSrc:jar UP-TO-DATE
> Task :buildSrc:buildSrc:assemble UP-TO-DATE
> Task :buildSrc:buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:buildSrc:test NO-SOURCE
> Task :buildSrc:buildSrc:check UP-TO-DATE
> Task :buildSrc:buildSrc:build UP-TO-DATE
> Task :rootBuildSrc:compileJava NO-SOURCE
> Task :rootBuildSrc:compileGroovy NO-SOURCE
> Task :rootBuildSrc:processResources NO-SOURCE
> Task :rootBuildSrc:classes UP-TO-DATE
> Task :rootBuildSrc:jar UP-TO-DATE
> Task :rootBuildSrc:assemble UP-TO-DATE
> Task :rootBuildSrc:compileTestJava NO-SOURCE
> Task :rootBuildSrc:compileTestGroovy NO-SOURCE
> Task :rootBuildSrc:processTestResources NO-SOURCE
> Task :rootBuildSrc:testClasses UP-TO-DATE
> Task :rootBuildSrc:test NO-SOURCE
> Task :rootBuildSrc:check UP-TO-DATE
> Task :rootBuildSrc:build UP-TO-DATE
> Task :included-build:buildSrc:nested:compileJava NO-SOURCE
> Task :included-build:buildSrc:nested:compileGroovy NO-SOURCE
> Task :included-build:buildSrc:nested:processResources NO-SOURCE
> Task :included-build:buildSrc:nested:classes UP-TO-DATE
> Task :included-build:buildSrc:nested:jar
> Task :included-build:buildSrc:nested:assemble
> Task :included-build:buildSrc:nested:compileTestJava NO-SOURCE
> Task :included-build:buildSrc:nested:compileTestGroovy NO-SOURCE
> Task :included-build:buildSrc:nested:processTestResources NO-SOURCE
> Task :included-build:buildSrc:nested:testClasses UP-TO-DATE
> Task :included-build:buildSrc:nested:test NO-SOURCE
> Task :included-build:buildSrc:nested:check UP-TO-DATE
> Task :included-build:buildSrc:nested:build
> Task :included-build:buildSrc:compileJava NO-SOURCE
> Task :included-build:buildSrc:compileGroovy NO-SOURCE
> Task :included-build:buildSrc:processResources NO-SOURCE
> Task :included-build:buildSrc:classes UP-TO-DATE
> Task :included-build:buildSrc:jar
> Task :included-build:buildSrc:assemble
> Task :included-build:buildSrc:compileTestJava NO-SOURCE
> Task :included-build:buildSrc:compileTestGroovy NO-SOURCE
> Task :included-build:buildSrc:processTestResources NO-SOURCE
> Task :included-build:buildSrc:testClasses UP-TO-DATE
> Task :included-build:buildSrc:test NO-SOURCE
> Task :included-build:buildSrc:check UP-TO-DATE
> Task :included-build:buildSrc:build
> Task :compileJava NO-SOURCE
> Task :processResources NO-SOURCE
> Task :classes UP-TO-DATE
> Task :jar
> Task :assemble
> Task :compileTestJava NO-SOURCE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE
> Task :test NO-SOURCE
> Task :check UP-TO-DATE
> Task :build

Execute ./gradlew build --console=plain
The console output contains tasks like

:rootBuildSrc:compileJava: OK
:buildSrc:buildSrc:compileJava: NOK. I would have expected :rootBuildSrc:nested:compileJava
:included:buildSrc:compileJava: NOK. I would have expected :includedBuildSrc:compileJava
:included:buildSrc:nested:compileJava: NOK. I would have expected :includedBuildSrc:nested:compileJava

Your Environment
No build scan yet, as I'm working on providing build scan support for buildSrc builds.

The root cause here is that the buildSrc of a project must be built before evaluating that settings.gradle for that project, and therefore before the root project name can be known. This is so that the logic from buildSrc can be used in the settings.gradle file. This is not the first time this has caused problems.
It's hard to see how this can be fixed without changing that fundamental aspect.

The behaviour has deliberately changed here - it will always use the included build dir name and not the project name, so that we have a consistent build path, even if that path does not match the included build root project name.


Adds hour5 space shooter project (without exercises solutions)

Basic space shooter - shooting asteroids and tracking score.

Your email used in the commit is not linked to your GitHub account. This is not really a problem, but the commit won't be associated with your account.

Oh I didn't realize that, thanks for pointing it out! I used the git desktop client this time for convenience and forgot to change the credentials there! I changed it so that next time it will be the same. For now it is fine though!


[W-10811389] fix typos

ref: W-10811389

fix typos
rename some of the images to avoid spell check
escape curly brackets to reduce build warnings

Many file names are changed. These docs are EOL.


adding reference to newer Microsoft.Rest.ClientRuntime version

🎯 Summary

PIMS-###:

🔰 Checklist

[ ] I have read and agree with the following checklist and am following the guidelines in our Code of Conduct document.

I have performed a self-review of my code.
I have commented my code, particularly in hard-to-understand areas.
I have made corresponding changes to the documentation where required.
I have tested my changes to the best of my ability.
My changes generate no new warnings.

Codecov Report

Merging #23 (9c0d04c) into dev (77ba6b0) will not change coverage.
Report is 1 commits behind head on dev.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##              dev      #23   +/-   ##
=======================================
  Coverage   64.70%   64.70%
=======================================
  Files         419      419
  Lines       13397    13397
  Branches     1278     1278
=======================================
  Hits         8668     8668
  Misses       4303     4303
  Partials      426      426

Flag
Coverage Δ

unittests
64.70% <ø> (ø)

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