Daggerizing without littering

Problem
By default, daggerizing an existing project (either with dagger init --sdk=NAME, or dagger develop --sdk=NAME) will cause littering, by mixing Dagger-managed files with pre-existing files. This can cause frustration and confusion just as a user is familiarizing themselves with Dagger.
Experienced Daggernauts can avoid this littering by explicitly setting --source to a subdirectory. But 1) this is cumbersome 2) it prevents a shared convention on default source directory 3) it doesn't help beginners.
Solution
Change how the default source directory is selected, so that littering never happens by default.

Before
After

Source directory, if module root is empty
. ✅
. ✅

Source directory, if module root is not empty
. ❌
.dagger✅

Design considerations
Custom boilerplate
@helderco asks:

What if I want to customize my language-specific boilerplate, for example with my own Python config files? This requires creating files before dagger init, which would trigger the .dagger behavior, but I don't want that.

In this case, you actually want to override the anti-littering protection: you're OK with the Dagger SDK mixing files into your directory, because you know what you're doing. It's reasonable to express that with an explicit --source ..
Weird to have code in .dagger
One concern with .dagger is that it feels weird to have source code in a dot directory, and may possibly confuse some IDEs.
I acknowledge the concern, but I think it's the best tradeoff:

In spite of thorough bikeshedding, we have not found an alternative that got stronger consensus
IDEs don't seem to be actually confused. Github actions using .github/workflows works to our advantage
Using a dot directory as "annotation" is a familiar pattern. Again, .github works in our favor.
The "weird" feeling is proportional to the size of the module source code. If it grows too large, we actually want you to spin it out into standalone modules. So the gradual "weirdness" factor works in our favor, because it acts a nudge towards desired best practices.

I significantly prefer this option to trying to mix dagger code into the project root in an SDK-specific way (like internal/dagger). For one, this option as suggested is actually relatively easy to implement - no significant SDK changes are required, and source keeps it's meaning. This also means backwards compatibility at a module level is very easy.
One question - do any languages struggle with importing code at hidden folders, like .dagger? I'm not sure how that might be done in python for example (go isn't an issue). I don't think this use case is super common, but may be an issue.
I do have one little feeling that changing the behavior of dagger init based on the contents of the current directory is confusing - I can imagine users getting confused why this would be different - that's a hunch though, since it's breaking from tradition of git init and co. I'm happy to try it, and get feedback.
Ignoring that though, we need to work out what "empty" means - I think a .git directory should probably be allowed in an "empty" directory, and in that case, any .gitattributes and .gitignore files should also probably be allowed. Does that extend to all hidden files?

Yes. .dagger feels natural: 🎬 https://www.youtube.com/watch?v=g2E86Ke_RME&t=445s

I agree with @jedevc. I remember suggesting a while back switching the default for source based on existing contents when discussing https://github.com/dagger/dagger/issues/6963#issuecomment-2057003774 with someone, and we scoffed it up due to it being possibly confusing. But I do still like that idea, so also happy to try it.
I dislike .dagger though, or more specifically, for it to be a hidden directory. I don't see it as the same as .github because that holds configuration and is not a proper programming language package. I'd love to see some examples of that.

My IDE's tree viewer does hide hidden directories by default, even though it's easy to show them with a shortcut
I use tools like rg, including the Live Grep in my IDE to search code in the project, that ignore hidden directories by default
I sometimes use macOS Finder to manage directories that may contain modules like my daggerverse or throwaway repros, which also hides hidden files by default

I mentioned in https://github.com/dagger/dagger/issues/7199#issuecomment-2113463263 that I'd prefer dagger.mod over that, or anything else that's not a hidden dir.
On the other hand, the above makes me think that the vendored library (now dropped in ./sdk), would benefit from being in an hidden directory like .sdk (or .dagger-io since we may want to stop referring to the client library as the "sdk").

Experienced Daggernauts can avoid this littering by explicitly setting --source to a subdirectory.

If they manage to remember (which gets complicated by the fact that this behavior changed a lot lately)

Weird to have code in .dagger

I don't mind it at all! It may get hidden by IDEs, but same is true for .github. I can live with that.
That being said, I'm kinda used to dagger as well.

I'm really digging this proposed solution, but I also believe defaulting to .dagger might introduce more troubles with other tools than dagger, which I never had an issue with. On the contrary, I prefer the name to signal it's a core part of the project. A hidden directory could go against that.

Relevant comment by @matipan : https://github.com/dagger/dagger/pull/8042#issuecomment-2253212160

My major concern with using a dot folder is that they are often referred to as hidden folders/files. Going into a terminal and doing an ls on the project would, by default, not show all the dagger specific codebase. Many fuzzy finders also ignore dot folders and files by default (like fzf, ctrl-p and others). Our point with Dagger is that your CI is an important part of your project that you should treat as regular software. Putting the contents of the top level module that builds, packages and releases our software project into a hidden folder makes it feel less relevant. I understand that this approach is already present, such as .github, but I honestly never liked it and I believe dagger code has more importance than the config files often written into . folders.

Relevant user comment: https://github.com/dagger/dagger/pull/7864#issuecomment-2283607492

For reference, I did this (and I've been doing ci/cd for a while):

Came to dagger.io and perused the docs (guilty for assuming)
Went to the quickstart and followed the quickstart in MY repo
Churned

Mmm, the comment above kind of convinces me that we should at least try the switching behavior based on the contents of the target directory. I still think it's confusing for users who do this a lot, but I think we've actually trained muscle memory for a lot of people to manually specify --source= in the past. I don't really like it, but if we don't want to update the quickstart instructions for different paths for initializing in an existing project vs a new project, then I think it's the only real option.
I do think we should make sure to have a neat message about where we initialized source to, and why - something like source directory initialized in dagger/ (because current directory was not empty).
I think there's enough here for someone to pick this up (will give it a try when I get a moment, and have cleared up my current work) - we still would need to decide about dagger vs .dagger - I'm a bit more tempted on dagger, given above points.

In my opinion, you're still hyper-focused on the dagger internals instead of giving new users a better intuitive understanding of what you know.  For example, you should have Project Layout at the top level of your documentation, probably between Introduction and Installation.  For example, explain this structure and why we need it:
.
├── dagger
│   ├── package.json
│   ├── sdk
│   ├── src
│   │   └── index.ts
│   └── tsconfig.json
├── your_project/
├── LICENSE
└── dagger.json

What I realize now is the above structure is required for TS/JS monorepos, but not enforced by dagger init.  I assume similar problems would surface with other languages, but I don't know that for certain.
Additionally, consider this module layout says nothing about where my source code should reside.  That's what bit me

@drmikecrowe here is the problem statement in this issue:

By default, daggerizing an existing project (either with dagger init --sdk=NAME, or dagger develop --sdk=NAME) will cause littering, by mixing Dagger-managed files with pre-existing files. This can cause frustration and confusion just as a user is familiarizing themselves with Dagger.

Experienced Daggernauts can avoid this littering by explicitly setting --source to a subdirectory. But 1) this is cumbersome 2) it prevents a shared convention on default source directory 3) it doesn't help beginners.

Which part specifically is hyper-focused on dagger internals over user experience? I'll make sure to correct it.

@drmikecrowe I'm trying to understand the problems you describe in [this comment] (https://github.com/dagger/dagger/pull/7864#issuecomment-2283607492), and whether it's related to this "littering" issue.

dagger init happily installs alongside my app (and did, leading me to be involved with this PR due to all the issues I was having)

Reading between the lines, it seems that you typed dagger init --sdk=typescript at the root of your repo, and did not specify the --source=./dagger argument specified in the quickstart. As a result your repo was littered with files, causing conflicts between your existing app and the new app dagger tried to drop at the source.
The quickstart avoids this problem by explicitly specifying --source=./dagger but you skipped it, thinking "if this were absolutely necessary, it would be the default behavior, and wouldn't require an explicit flag". Which as it turns out is not the case, causing frustration.
Is this ☝ correct? If so, then you are indeed experiencing the "littering" problem which we aim to solve with this issue. And you are correct that as a result, we should be able to document the standard project layout better than we do today.

Which part specifically is hyper-focused on dagger internals over user experience? I'll make sure to correct it.

None -- sorry.  I thought source was referring to dagger/src.  My bad

In my opinion, you're still hyper-focused on the dagger internals instead of giving new users a better intuitive understanding of what you know.

I've found this mentality as well. I can't remember the exact specifics (so take this as anecdotal), but it was around things like enums and scalars.  The reasoning that I got was centered around the fact that 'thats not the way that GraphQL does things', which came across as odd since, at least from my perspective as a user, the fact that GraphQL is being used seems like an implementation detail

In my opinion, you're still hyper-focused on the dagger internals instead of giving new users a better intuitive understanding of what you know.

I've found this mentality as well. I can't remember the exact specifics (so take this as anecdotal), but it was around things like enums and scalars. The reasoning that I got was centered around the fact that 'thats not the way that GraphQL does things', which came across as odd since, at least from my perspective as a user, the fact that GraphQL is being used seems like an implementation detail

I agree and I apologize if you encountered this. Our philosophy is to always focus on the user experience first. But we are not perfect and occasionally deviate from this. It's a large and complicated system, and sometimes we can get lost in the weeds. Please always flag this right away when you encounter it, ideally with @shykes, and I promise we'll address it right away.

Is this ☝ correct? If so, then you are indeed experiencing the "littering" problem which we aim to solve with this issue. And you are correct that as a result, we should be able to document the standard project layout better than we do today.

Nailed it -- but, that doesn't seem to fundamentally solve the issue with JS/TS Monorepos and #7864.  I did dagger init --sdk=typescript --source=./dagger and got:
Stderr:
error This project's package.json defines "packageManager"<EMAIL_ADDRESS>However the current global version of Yarn is 1.22.22.

with this:
  async test(directoryArg: Directory, pattern: string): Promise<string> {
    return dag
      .container()
      .from('alpine:latest')
      .withMountedDirectory('/mnt', directoryArg)
      .withWorkdir('/mnt')
      .withExec(['yarn', 'install', '--immutable'])
      .stdout()
  }

So, my core issue we're discussing in the other issue is relevant here in terms of the project layout I'm advocating you enforce. If you see what @TomChv pointed out here, I'm feeling that should be mandatory rather than suggested

Thanks for clarifying @drmikecrowe. So if I understand correctly, you did run dagger init --sdk=typescript --source=./dagger, but that didn't prevent the package.json defines "packageManager" error? This is concerning to me, because it suggests that the solution proposed in this issue might not be enough.
Did you track down the root cause of the issue, and how to fix it? cc @TomChv

error This project's package.json defines "packageManager"<EMAIL_ADDRESS>However the current global version of Yarn is 1.22.22.

The interesting part with yarn is that both 1.22.22 and 4.1.1 are actually the same binary.  The specific version can be controlled with the .yarnrc file so it can differ depending on which directory you are in

See this comment
Here's what I'm starting to believe:

It's almost impossible to install dagger within a folder with an existing package.json.  It appears it must be 1 level above
If you try to install dagger in your folder (as I did), the SDK yarn install will update the yarn.lock, which breaks our CI later since we use yarn install --immutable)
Also, our top-level package.json has packageManager: "4.1.1" field, which causes the SDK install to fail before it even tries to execute

The one way to solve this is to not include the dagger module in the list of yarn workspaces and give it its own yarn.lock file.  This is far from ideal though.
I currently have my dagger module in a separate repo and I am getting pressure internally to move it into our monorepo, and this the major blocker for that (Although in my case I prefer to have it in its own repo, but that is specific to me and my org)

I am concerned by this comment by @drmikecrowe:

In short, I think dagger's package.json and the project's package.json must be in parallel folders. I don't see how they can be parent/children with any monorepo setup

If this is true, then the solution we are discussing here might not work for the Typescript SDK. In other words, we may not have a good solution for a Dagger module co-existing in a host repo, when both are written in Typescript/Javascript.
Thoughts @TomChv @jedevc @marcosnils @sipsma @vito ?

If this is true, then the solution we are discussing here might not work for the Typescript SDK. In other words, we may not have a good solution for a Dagger module co-existing in a host repo, when both are written in Typescript/Javascript.

I had similar issue when using dagger in its own repo as well since the sdk and module are installed separately

The one way to solve this is to not include the dagger module in the list of yarn workspaces and give it its own yarn.lock file. This is far from ideal though.

@xiot -- can you confirm this works?  I was unable to get this working

I don't have dagger in my monorepo so its a little more involved for me to test.
I do have packages in my monorepo though that are excluded from the list of workspaces and have their own lock file, so I was mainly going off of that.

@drmikecrowe @Xiot  think I was able to reproduce your issue and even after https://github.com/dagger/dagger/pull/7864 seems like it's still not fully resolved.  Copying my message from discord (https://discord.com/channels/707636530424053791/1271408553848209491/1273133304849371199) here:

I was able to reproduce what the user was experiencing in v0.12.4
npm init -y
corepack use<EMAIL_ADDRESS>dagger init --sdk typescript --source dagger
dagger call container-echo --string-arg foo
^ this fails with:
Error: input: module.withSource.initialize resolve: failed to initialize module: failed to call module "l
olo" to get functions: call constructor: process "yarn install" did not complete successfully: exit code:
1
Stderr:
error This project's package.json defines "packageManager": "yarn<EMAIL_ADDRESS>However the current global
version of Yarn is 1.22.22.
this is my current directory layout:
.
├── dagger
│   ├── package.json
│   ├── sdk
│   ├── src
│   ├── tsconfig.json
│   └── yarn.lock
├── dagger.json
├── LICENSE
├── package.json
└── pnpm-lock.yaml
4 directories, 7 files
why is this failing? it doesn't seem right that the runtime container is trying to use pnpm when the module's package.json doesn't have a packageManager defined. Why is dagger call picking up the parent's package.json packageManager config?
I've tested with the latest version in main and the issue is still not resolved, something even more strange is happening.  After doing dagger init , the root application  package.jsongets overwritten with this value:   "packageManager"<EMAIL_ADDRESS>

I like .dagger, this to me feels like an external process will be using this, which is how it feels and will be, i.e a CI Pipeline,will be using it or the local dagger cli. With dagger, it could be assumed as a normal compiled set of code which isn't the case. however, The . is commonly known to be a hidden directory but then we have cases where for the average developer, it shouldn't be an issue, i.e .git or the many . prefixed folders found in a ~ home directory (nuget config, dotnet, k8s config, .ssh` etc.
Any thoughts on private modules being .dagger and modules meant to be published or public for external use, to be in a dagger folder?

I prefer using dagger instead of .dagger. Many reasons have been presented in this issue, and I agree with most of them (specially @helderco 's). It has an impact on the experience, IDE(s) will hide it, and more importantly, it's not just a decorative aspect of my repositories, it's fundamental, it's the codebase that powers my Continuous Integration. Having it hidden makes readability difficult, especially for those less experienced with Dagger.

It can be overwritten with --source= if necessary.

That's what I usually use, and if this is developed, it'll be my first approach permanently for creating new modules.

It’s a better experience for first-time users, with less friction, than just erroring out.

It's difficult to evaluate that. I believe it's a trade-off; it may solve one problem but introduce another (hidden folders will create an additional obstacle).

Hi @Excoriate
Many thanks you for your feedback on this issue (and other contributions, thanks to one of your daggerverse module, we were able to identify some backward imcompatible changes in one of the other PR 🎉).
FWIW, I prefer to have anything except my app code to be shown less prominently on the IDE. Mostly because I would be spending the cycles to set up that once, and then focus on my app changes. but this is my personal preference and I appreciate the fact that it could be different for other folks.
having said that, I am happy to change the default to dagger if that is what we agree upon as a team. cc @helderco @shykes @marcosnils @jedevc for helping us make a final decision here.


-lpthread revert broke gccgo on ppc64le (at least)

The -lpthread option is required for pthread trylock under gccgo at least for ppc64le (likely more architectures too).
If setting it for everyone breaks some cases, can we at least keep it for gccgo+linux?

@minux is it possible to avoid this with something like #cgo gccgo LDFLAGS -lpthread ?

libgo itself requires pthread, so i don't understand how could you link a
Go program without -lpthread implied.
How to produce this? This might be a problem of the go tool bundled
with gccgo.
/cc @ianlancetaylor

We're running into that issue using gccgo 5.0 on ppc64le (and I suspect on other arches too but I don't have access to arm64 right now to confirm)

OK, the gccgo go tool should add -pthread to the final linking command,
to match the behavior the gc (where the runtime/cgo package will add
-lpthread as needed.)

So it may well be that gccgo is the problem, unfortunately changing the compiler isn't something I can trivially do, and retro-actively doing so for existing older releases is even less likely to happen.
Can anyone think of a problem with using:
#cgo gccgo,linux LDFLAGS: -lpthread

That should be specific enough not to affect anyone else.

How does this problem arise?  As minux said, libgo is already linked against libpthread.  When linking statically, the gccgo driver adds an explicit -lpthread.  So what precisely are you doing to cause a problem?  And what precisely happens?

Still not sure exactly what's going on as I can't reproduce the issue with a simple example but can when attempting to build our project (and its ton of dependencies).
Anyway, looks like adding -lpthread to our own cgo file fixes things so I'll just do that.


Remove uncesssary tokens

Changes made:

removed CDO & CDC tokens since we ignore comments during lexing via the discard_comments function defined in packages/parser/lib/css_lexer.re.
removed the BAD_STRING token because the css_parser ensures all strings are correct.
renamed some tokens.

Changes referenced in https://github.com/davesnx/styled-ppx/pull/368


Add proposals directory for storing proposal & Add TEMPLATE.md to guide how to write a proposal

Maybe we should add a proposal template for those who want to contribute? So when people want to make some contribution, they can describe their implementation in the proposal
Signed-off-by: yuzhipeng<EMAIL_ADDRESS>

This is great. But I guess we can put a link to this template somewhere, so people can easily know it.

Hi! I don't think README.md is a good place to put links. Maybe we need a file like CONTRIBUTING.md so that we can put the link in it.

Maybe we need a file like CONTRIBUTING.md so that we can put the link in it.

+1 from me

Hi @LinuxSuRen  I am sorry to bother you.  Can you help me merge this pullrequest or what should I should do to merge this pullrequest ?


Add Gizmo to display 3D custom AABB

This PR adds the ability to preview the custom AABB of a MeshInstance3D inside the editor.

Tested locally (rebased on top of master https://github.com/godotengine/godot/commit/a7b860250f305f6cbaf61c30f232ff3bbdfdda0b), there are issues with the gizmo shape not being updated when you change the Custom AABB property in the editor:
https://github.com/godotengine/godot/assets/180032/45a95810-54b9-4bf6-a90e-601f0c3ea266
The gizmo only updates if the mesh resource is changed or if you deselect and reselect the node.

Yes but I think this is the limitation of the gizmo. I don't really know how to make it update automatically.

Yes but I think this is the limitation of the gizmo. I don't really know how to make it update automatically.

You can force a gizmo update by calling update_gizmos() at the end of GeometryInstance3D::set_custom_aabb():
https://github.com/godotengine/godot/blob/6c579280630715ff7da8310d405ef34194847294/scene/3d/visual_instance_3d.cpp#L374-L380

Yes but I think this is the limitation of the gizmo. I don't really know how to make it update automatically.

You can force a gizmo update when the property is changed by calling update_gizmos() at the end of GeometryInstance3D::set_custom_aabb()
Thanks for the tip!

Thanks!


Containerd config injector

Containerd startup config is modified by adding extra options:
sandbox_image = "{{ .PauseImage }}:{{ .PauseImageTag }}"
enable_unprivileged_ports = true
enable_unprivileged_icmp = true
This is done via xtoml binary

Do we run into issues when https://repo.eu-de-1.cloud.sap/xtoml/xtoml is unreachable due to issues in the metal controlplane, so that metal nodes cannot be created/rebooted anymore?

@xsen84 Can you comment of @Nuckal777's remark. Can we live with a swift dependency for bootstrapping on-metal nodes. cc @SchwarzM

Discussed this in out kubernetes weekly and agreed to change this PR to pull the binary via a docker image from keppel.global similar to how we do it for the kubelet. This avoid adding a hard dependency to swift in eu-de-1 from all regions

@databus23
with the docker image approach I hit another issue:

containerd service needs to start after the config_replace service,
config_replace service needs docker service  to pull the image with the binary,
docker service needs containerd service

... and all this causes a dependency loop

minion-4c07d928741c ~ # systemctl status docker
○ docker.service - Docker Application Container Engine
Loaded: loaded (/run/systemd/system/docker.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─20-docker-opts.conf
Active: inactive (dead)
TriggeredBy: × docker.socket
Docs: http://docs.docker.com
Nov 24 08:24:16 minion-4c07d928741c.cc.qa-de-1.cloud.sap systemd[1]: docker.service: Found dependency on docker.service/start
Nov 24 08:24:16 minion-4c07d928741c.cc.qa-de-1.cloud.sap systemd[1]: docker.service: Job containerd.service/start deleted to break ordering cycle starting with docker.service/start
Nov 24 08:24:17 minion-4c07d928741c.cc.qa-de-1.cloud.sap systemd[1]: containerd-config-replace.service: Found ordering cycle on docker.service/start
Nov 24 08:24:17 minion-4c07d928741c.cc.qa-de-1.cloud.sap systemd[1]: containerd.service: Unable to break cycle starting with containerd.service/start

a possible solution would be to restart the containerd service once we got the desired containerd config in place:

[Unit]
Description=Modify startup configuration file of containerd
After=network-online.target docker.service
Wants=network-online.target
[Service]
User=root
WorkingDirectory=/opt/bin/
ExecStartPre=docker run --rm -v /opt/bin:/opt/bin keppel.global.cloud.sap/ccloud/xtoml:v1.0.0 cp /usr/local/bin/xtoml /opt/bin/
ExecStart=/opt/bin/containerd-config-replace.sh
ExecStartPost=systemctl daemon-reload
ExecStartPost=systemctl restart containerd
[Install]
WantedBy=multi-user.target

it works, but is not quite nice
i open for suggestions

using
https://repo.{{ .OpenstackRegion }}.cloud.sap/controlplane/xtoml/xtoml
to download binary
change is already deployed  in qa-de-1  apod/virtual


docs: update I want to write a test section [ci skip]

This PR resolves []
Description
Noticed that we encourage people to use test-id to query components, while @testing-library/react-native has different suggestions on querying components. Updated our docs to reflect to the best practices of the community 😊
I will also update the example links during the refineathon :)
read more info here 👇
How should I query?

PR Checklist

[ ] I tested my changes on iOS / Android.
[ ] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.
[ ] I added an app state migration.
[ ] I hid my changes behind a feature flag.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

updated how to test docs - gkartalis

Need help with something? Have a look at our docs, or get in touch with us.

do we have a good example to link underneath?

Great point, will find some examples and update the links, was thinking to update the links during the refineathon but rather sooner than later

Thanks for showing our docs some love 🎉


Suggest to change XmlnsPrefix casing to lowercase.

I suggest to change the XmlnsPrefix from Interactions to interactions since other libraries uses lower case to and ReSharper suggests me to change the casing to lowercase.

Name 'Interactions' does not match rule 'Namespace alias'. Suggested name is 'interactions'.

PR referenced: #28

I would actually prefer to see a shorter prefix such as just i instead of a full interactions.
Actually, I think it's strange that a Microsoft.Xaml.Behaviors namespace maps to an interactions prefix. Doesn't it make more sense to map to a behaviors prefix or simply a b?

I like Shorter prefixes too, should i change the PR to that one so that the cange can, later, be merged?


Focus issue on CreateFullPage with modal

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)
[ ] Legacy/CDAI
[ ] Legacy/Security

Detailed description

Describe in detail the issue you're having.

I am using the CreateFullPage component and had a question with accessibility. I clicked on the cancel button on the FullPage and it opened up a modal and when I press tab, it focuses on the enabled next button on the outside before going into the modal. Is there a way to shift focus on the modal?
It is also seen here https://carbon-for-ibm-products.netlify.app/?path=/story/ibm-products-patterns-create-flows-createfullpage--create-full-page

Is this issue related to a specific component?

CreateFullPage

What did you expect to happen? What happened instead? What would you like to
see changed?

The focus should be on the modal instead of the outside

What browser are you working in?

Chrome and FireFox

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive)
package are you using?

"@carbon/ibm-products": "^1.43.0",

Additional information

@hkang92 this was addressed in #2790 which should be available in our next release!


This is amazing

Sorry for filing a non-issue but I think it needs to be said, this application is amazing and you are amazing developers for sharing it with the world.  I dream of a world wide web that is browsable from curl.
Thank you!

@matthewp Matthew thank you!
(please don't be surprised; I am going though the ancient issues and close the ones, that do not need any fixes)


[FLINK-9665] PrometheusReporter does not properly unregister metrics

What is the purpose of the change
Prometheus metrics from canceled jobs are not always correctly cleaned up. This patch aims to remedy this
Brief change log

always unregister childs from collectors in notifyOfRemovedMetric so that no metrics stay behind when a job gets canceled but the collector does not get unregistered

Verifying this change
I added a metricIsRemovedWhenCollectorIsNotUnregisteredYet test to PrometheusReporterTest
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature?: no
If yes, how is the feature documented?: not applicable

Hi, @jelmerk, I have a question that when will there be two taskmanager registered in the same registry?

@lamber-ken If you are referring to the added test, it covers the case of 2 jobs (TaskManager>>Job<<MetricGroup) in the same registry, not TaskManagers.
There will usually not be multiple TaskManagers registered in a single registry, but this issue applies in general to any subset of metrics with the same logical scope.

I've merged the PR, @jelmerk could you close it? Thanks!


New name for Android Support Repository

Description
Update the name of Android Support Repository in the docs. It's been changed to Local Maven Repository for Support Libraries in the Android SDK.
Related Issue
#763
Motivation and Context

I followed the INSTALLATION steps and was not able to build because the dependency listed is no longer int he Android SDK.
How Has This Been Tested?

I installed the new package and compiled my app successfully.
Screenshots (if appropriate):
Types of changes

[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 change)
[X] Documentation only.

Checklist:

[x] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[x] All new and existing tests passed.

Android Support Repository has been renamed to Local Maven repository for Support Libraries in the Android SDK.
This commit updates the docs to reflect that fact.

For anyone that hasn't updated the Android SDK Manager, the label will still be Android Support Repository, and that new label will only appear once you update the SDK Manager. Can we mention both of them instead?


RFC: etcdserver: not count unreachable nodes as a started node during reco…

…nfig
-strict-reconfig-check option ensures a quorum cannot be losed by
membership reconfiguration even if unstarted nodes are misconfigured
(e.g. typos in peerURLs). As suggested in [1], this commit lets
isReadyToAddMember() not to count unreachable nodes as started nodes.
This PR isn't ready to merge. I'd like to hear the maintainers' opinion especially in the below points:

Is it correct to use EtcdServer.ReportUnreachable() for detecting unreachable nodes?
This PR doesn't have a mechanism of detecting revival of unreachable nodes. What mechanism can I use for the detection?
I'm really glad if I can hear your comments.

[1] https://github.com/coreos/etcd/pull/3543#issuecomment-141509597

Is it correct to use EtcdServer.ReportUnreachable() for detecting unreachable nodes?

This PR doesn't have a mechanism of detecting revival of unreachable nodes. What mechanism can I use for the detection?

I would suggest to use transport.ActiveSince because it meets your requirement already. Ref: https://github.com/coreos/etcd/blob/master/rafthttp/transport.go#L88 .

@yichengq thanks a lot for your advice. As you say, transport.ActiveSince() seems to be suitable for the purpose. I updated this PR based on the function. Could you review it?

Test is failing because of the update introduced by this PR. I'm fixing it.

Already fixed by @heyitsanthony with https://github.com/coreos/etcd/pull/6156

@xiang90 ah I see, thanks a lot @heyitsanthony !


Installing SAP HANA 2.0, express edition (Virtual Machine Method)

Hi -
Quick check - My machine configuration is 4 GB RAM 1 TB hd, on a i7 Windows machine. Would you recommend me to go ahead with this installation or do you see a limitation in terms of hardware?
Kindly suggest.

Hi - Your PC needs more RAM. The tutorial http://www.sap.com/developer/tutorials/hxe-ua-installing-vm-image.html lists these machine requirements:
Hardware

RAM - 16 GB RAM minimum. 24 GB RAM recommended.

HDD 120 GB HDD recommended.

Cores - 2 cores (4 recommended).

Hardware Virtualization - (Intel processors only) For Intel processors, virtualization is a BIOS setting known as either Intel Virtualization Technology or Intel VT. Go to Determine If Your Processor Supports Intel Virtualization Technology to determine if your processor is capable of supporting virtualization. If virtualization is turned off on your virtualization-capable machine, consult documentation from your machine vendor on how to enable virtualization technology (or Intel VT) in the BIOS.

Hope this helps,
John C.


Ability to release Spring Monitor independently of the OTel exporter

API change check
API changes are not detected in this pull request.


dotnet nuget verify doc

Summary
dotnet 5.0.100-rc.2.x SDK has added dotnet nuget verify command.
Happy to iterate to make the doc better based on feedback.
Fixes #20701

This looks great, I have just a few suggestions

Thank you @tdykstra for the feedback. I have committed all suggestions. Can we merge this PR now or wait for additional approvals?


[#154]-[Add mod_time column for former_animal_owner table]

Workshop task (Database Issues A, No. 6 from slides).
Resolves issue #154

Looks good! We might need to cherry-pick 15a6001 if the fork sync doesn't remove unnecessary file changes.

Maybe there’s something I can do on my local branch to make it more appropriate?


Drop support for urllib

This would mean either making requests an explicit dependency, or vendoring it.  There's a bunch of stuff that requests gives us that is just plain smart (verify=True, more sensible retry policies, etc.)  Right now we abstract away the smarts which makes it hard to implement features like #26.

The switch from a bespoke resolver to using vendored Pip under the hood solved this issue for the most part. The vendored Pip and any bootstrapped Pip's do use their own vendored requests and Pex is left using its URLFetcher wrapper over urllib for these activities:

Bootstrap Pip from https://bootstrap.pypa.io/pip/ when creating or updating a venv with an interpreter that does not support -m ensurepip. (rare)
Fetching PEP-691 file hash metadata when creating locks via pex3 lock {create,sync,update}.
Fetching the science binary from https://github.com/a-scie/lift/releases when building a native PEX (--scie {eager,lazy}. (~one time operation - cached)
Parsing -r <URL> requirements, which preserves a Pip feature. (rare)

Of these, only the PEP-691 case is hit regularly for lock users. The discovered metadata is cached with no TTL; but any lock update using PyPI, which supports PEP-691 is going to exercise URLFetcher urllib code. That code does support timeouts as well as the equivalent of requests verify={True,/path/to/cert-bundle} and has now been battle tested for several years to be at least decent enough to not net bug reports. Since Pex has gone the route of being dependency free, that leaves vendoring a version of requests still compatible with Python 2.7; i.e. requests==2.27.1. That nets a ~600KB size-increase to the ~3.5MB Pex wheel. Although not unreasonable, there's just no current impetus to take on this dependency with the improvements to urllib use that have transpired.


We need proper notification when we ran out of task

At the moment 2/3 of tasks we have already processed. So in few days we'll ran out of work.

Fixed by me by adding extra event

:+1:


WIP: Add API endpoint to get time zone names

GET /api/v1/i18n/tz/names (path subject to change!) returns a mapping of
time zone IDs to human-readable names in the specified locale, US English by
default. The list of time zones is based on Chrome's supported time zone list,
minus zones that appear to be duplicates.
The end result is very close to the list of time zones in the Google Calendar
time zone menu (not that Google Calendar is the ultimate authority on time
zones, just a useful comparison point).
This is missing documentation and tests at the moment; it's kind of the tail
end of a bunch of exploratory coding I was doing to figure out if it was possible
to generate this output without resorting to manual curation of the zone
information.

Current dependencies on/for this PR:

main

PR #881   👈

This comment was auto-generated by Graphite.

Some examples. English:
    "Africa/Abidjan": "Greenwich Mean Time - Abidjan",
    "Africa/Nairobi": "East Africa Time",
    "Africa/Algiers": "Central European Standard Time - Algiers",
    "Africa/Lagos": "West Africa Standard Time - Lagos",
    "Africa/Bissau": "Greenwich Mean Time - Bissau",
    "Africa/Maputo": "Central Africa Time - Maputo",
    "Africa/Cairo": "Eastern European Standard Time - Cairo",
    "Africa/Casablanca": "Western European Time - Casablanca",

Spanish:
    "Africa/Abidjan": "hora del meridiano de Greenwich - Abiyán",
    "Africa/Nairobi": "hora de África oriental",
    "Africa/Algiers": "hora estándar de Europa central - Argel",
    "Africa/Lagos": "hora estándar de África occidental - Lagos",
    "Africa/Bissau": "hora del meridiano de Greenwich - Bisáu",
    "Africa/Maputo": "hora de África central - Maputo",
    "Africa/Cairo": "hora estándar de Europa oriental - El Cairo",
    "Africa/Casablanca": "hora de Europa occidental - Casablanca",

Simplified Chinese (this is not quite correct because it uses a space-separated ASCII hyphen; need to make the city name suffix format localizable too):
    "Africa/Abidjan": "格林尼治标准时间 - 阿比让",
    "Africa/Nairobi": "东部非洲时间",
    "Africa/Algiers": "中欧标准时间 - 阿尔及尔",
    "Africa/Lagos": "西部非洲标准时间 - 拉各斯",
    "Africa/Bissau": "格林尼治标准时间 - 比绍",
    "Africa/Maputo": "中部非洲时间 - 马普托",
    "Africa/Cairo": "东欧标准时间 - 开罗",
    "Africa/Casablanca": "西欧时间 - 卡萨布兰卡",

Steve, can you help with a theoretical example where there are no duplicate cities in one language - but present in another language and the dupes are removed?
I'm thinking about a scenario where uses changes preferred locale and we can no longer find the tz in the new list.. how do we find the closest match.. etc.

I'm thinking about a scenario where uses changes preferred locale and we can no longer find the tz in the new list.. how do we find the closest match.. etc.

This won't be possible, though that wasn't clear in the first draft of this PR. The list of zone IDs is determined based on the English names, and then we localize the names of those IDs. The updated version of this includes a unit test to verify that the list of IDs is identical in every locale.

To expand on that a little: whether or not we append a city name is determined on a per-locale basis (so it's possible for a localized name to have a city in one locale but not another), but the list of zone IDs is locale-independent.

The way I'm using resource bundles (the .properties files) here is kind of an initial stab. Once we get to the "support Spanish localization" project, I may end up wanting to structure the translations in a different way, but I haven't thought it through in enough detail yet and IMO this is a reasonable approach to start with.

The way I'm using resource bundles (the .properties files) here is kind of an initial stab. Once we get to the "support Spanish localization" project, I may end up wanting to structure the translations in a different way, but I haven't thought it through in enough detail yet and IMO this is a reasonable approach to start with.

This looks great for now and enables us to use curated values.


Fetch secret property prefix with {vault} directely in Hashcorp vault

Hello,
I would like to suggest a new feature to be able to fetch secret property prefixed by {vault} directly in Hashicorp vault.
For example, we can have this:
---
my-app:
  db:
    user: test
    password: '{vault}<secret engin path>#<secret key>

In my point of view, this is a better integration than using spring-cloud-config-server with the vault backend.
Indeed this pattern allows having a clear view of all properties in one place instead of having some properties in a git backend and some secret properties in a vault backend.
This pattern is also very convenient to integrate with the vault Kubernetes auth method.
I already implement this feature in my projects.
If you are interested I can publish a merge   ##request.
Best regards,
Julien Piccaluga

Check out spring cloud vault

Hi Spencer,
I open this issue in spring-cloud-common repo because it's here that you implement EnvironmentDecryptApplicationInitializer and this is very similar use case.
Do you suggest me to open this issue in spring-cloud-vault instead?
Regards,
Julien


OCPBUGS-30448: 4.16 2024-03-13 nightly rebase and bump of protobuf libraries

/override ci/prow/test-rebase
core rebase functionality works, only the last step related to the lvms images failed

/override test-rebase
core rebase functionality works, only the last step related to the lvms images failed

/lgtm


Is it able to hide the menu?

Hello,
I use windows10 and when I restart Joplin, I found it's really easy to unlock the software just by click Tools=>Options and then disable the lock plugin. Is it possible to hide the menus when start or is there any work around?

Will enlarge the white panel resolve this problem?

Sorry, there is no way to do something to this after I read all of Joplin apis: https://joplinapp.org/api/references/plugin_api/classes/joplin.html .


Add ProxyStore to the list of merchants

What's the name of your business?
ProxyStore
What's the URL of the website?
https://proxysto.re/en/bestellservice.html
Write a brief description of your business/service (max 50 characters)
order products via the proxystore within the eu
Enter the URL where a Monero mention can be found
https://proxysto.re/en/bestellservice.html
How do you accept Monero? (choose only one option)

[X] Other payment gateaway (BTCPay Server)

How would you categorize your business? (choose only one option)

[ ] Exchange
[ ] Block Explorer
[ ] Payment Gateway
[ ] Web Hosting
[ ] Tool
[ ] Service
[X] Goods
[ ] Entertainment

Comment
We are not only interested in enabling payments with monero, but our offer aims to enable data-saving or anonymous online shopping. https://proxysto.re/en/warum.html

OK


Quality flags

Where is the quality flag stored in the radar data?
Need to be able to access this to decide if we process or not.

Priority item for this week. Working on it actively in josh_dev. Current structure provides Boolean flag fields for aircraft dynamics and data quality. Basic functions for SNR analysis implemented.

QA flags for flight dynamics have been merged to master.
https://github.com/kingjml/pySnowRadar/pull/36


How can i get count of followers more than 20?

The "next" cursor allways bring me 20 of users, how can i get 1000?

Check check use info for method getUserFollowers in readme. With this method you receive all followers after sometime proccessing. For example, for 3.5k  followers - proccessing will be 3 min.

ok, thanks


feat: edit component unit test

I updated the unit test for the components file. If there is anything that failed the test, let's discuss it together

LGTM


Asynchronous Allreduce

Have you plan to support asynchronous allreduce ?
In current design (sync-allreduce), all nodes wait for allreduce result when gradient update. Have you plan to support async-allreduce ? Like,
Node-N wait-allreduce-result --> layer-1-forward --> wait-allreduce-result --> layer-2-forward --> ... --> layer-2-backward --> send-async-allreduce-request -->layer-1-backward --> send-async-allreduce-request.

Currently, we don't have a plan to support it.
(1) Communicating short-message over a network is very inefficient. Even if such communication-computation overlap improves the network hardware usage, it is not clear if it really improves the total computing time.
(2) We have implemented a double-buffering feature in ChainerMN. This works in a similar manner, and the implementation is much simpler.
(3) We don't have a particular target application, that is expected to be accelerated with the technique and worth the implementation effort. We are happy to hear from you if you have such a target application!! (Maybe on Ethernet-environment or AWS?)

I'm closing the issue, but please feel free to reopen it if you have further questions or have more discussion on this. Thanks!


[Improvement] Complete internationalization for some remaining pages

Why are the changes needed?

Close #xxx.
Brief change log

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 32.83%. Comparing base (08183b7) to head (ad8645a).
Report is 12 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #3011      +/-   ##
============================================
- Coverage     32.85%   32.83%   -0.03%
+ Complexity     3825     3819       -6
============================================
  Files           557      557
  Lines         46227    46238      +11
  Branches       6107     6114       +7
============================================
- Hits          15189    15181       -8
- Misses        29843    29860      +17
- Partials       1195     1197       +2

Flag
Coverage Δ

core
32.83% <ø> (-0.03%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Disconnected edges

Pull Request Description
Implements:

Click edge to disconnect from source or target end.
Disconnected edge is attached to mouse, snaps to node/expr.
Disconnected edge captures clicks.
Escape cancels operation.

Remaining in #7864:

Draw node output port, create disconnected edge on click.
Implement graph edits (createNodeFromEdgeDrop / createEdge / disconnectEdge).

Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

See #8138.


[Bug Report] DB migration failed

Describe the bug
I've tried updating from a dev build(2? weeks old, some time after #211(v0.22.0)) to the latest release(v0.23.0), and it just prints DB migration failed. The current version 12 does not exist in the versions list, unable to start again. Had to delete the mango.db file. Not sure if this was overlooked in the release, or rather I screwed something up by switching between builds like that.

Hi, the dev branch is not stable and would occasionally have breaking changes. In this case, it was because the DB migration version 12 was deleted from dev in this commit. The version 12 migration never existed in master so it only affects dev branch users.
In the original thread, you mentioned that you are using it in a separate container so hopefully you didn't lose any data?
In case someone else also run into this, you can easily resolve it by executing the following SQL queries in mango.db:
drop table subscription;
pragma user_version = 11;

Didn't use a separate container, but didn't lose any important data. Thanks for the response.


Add basic command line support (#40)

Add command line support to rollbar notifier, addresses #40

[x] collect argv and send it in build_server_data() (must have php directive register_argc_argv on, otherwise it'll not be set)
[x] send extra php_context variable for all errors, indicating the context in which the error happened (http or cli)
[x] add test coverage

cc @Crisfole

@nocive: I see this, the changes look really small and don't break any tests.  Any chance you have a demo of how this would work? (That demonstrates it works, for instance?)

sure, will work on that, was just aiming to get some early feedback if this would be the way to go about implemeting it ;)

@nocive This looks good to me I just want to see an example and I think I'll ear mark it for a merge...We've got lots of merging coming up in the next few days I think...we're long overdue.

@Crisfole here's a payload sample using the async/relayed rollbar setup with this exact same code running:
{"data":{"timestamp":1460564335,"environment":"test","level":"error","language":"php","framework":"php","notifier":{"name":"rollbar-php","version":"0.15.0"},"uuid":"973bc414-b357-4b19-b4d1-dafb084dbdb7","body":{"trace":{"frames":[{"filename":"##omitted##","lineno":31,"method":"<main>"},{"filename":"##omitted##","lineno":126,"method":"run"},{"filename":"##omitted##","lineno":96,"method":"doRun"},{"filename":"##omitted##","lineno":195,"method":"doRun"},{"filename":"##omitted##","lineno":882,"method":"doRunCommand"},{"filename":"##omitted##","lineno":257,"method":"run"},{"filename":"##omitted##","lineno":24,"method":"execute"}],"exception":{"class":"Exception","message":"rollbar error simulation"}}},"server":{"host":"##omitted##","argv":["somescript","-vvvv","test:command","--arg=value"]},"person":null},"access_token":"##omitted##"}

and pretty printed:
{
  "data": {
    "timestamp":<PHONE_NUMBER>,
    "environment": "test",
    "level": "error",
    "language": "php",
    "framework": "php",
    "notifier": {
      "name": "rollbar-php",
      "version": "0.15.0"
    },
    "uuid": "973bc414-b357-4b19-b4d1-dafb084dbdb7",
    "body": {
      "trace": {
        "frames": [
          {
            "filename": "##omitted##",
            "lineno": 31,
            "method": "<main>"
          },
          {
            "filename": "##omitted##",
            "lineno": 126,
            "method": "run"
          },
          {
            "filename": "##omitted##",
            "lineno": 96,
            "method": "doRun"
          },
          {
            "filename": "##omitted##",
            "lineno": 195,
            "method": "doRun"
          },
          {
            "filename": "##omitted##",
            "lineno": 882,
            "method": "doRunCommand"
          },
          {
            "filename": "##omitted##",
            "lineno": 257,
            "method": "run"
          },
          {
            "filename": "##omitted##",
            "lineno": 24,
            "method": "execute"
          }
        ],
        "exception": {
          "class": "Exception",
          "message": "rollbar error simulation"
        }
      }
    },
    "server": {
      "host": "##omitted##",
      "argv": [
        "somescript",
        "-vvvv",
        "test:command",
        "--arg=value"
      ]
    },
    "person": null
  },
  "access_token": "##omitted##"
}

I'm also thinking about including the context variable as a server argument, so that you can clearly see from the rollbar backend and notifications what the error execution context is (possible values: http or cli).

@brianr done, also added php_context to server_data and fixed a couple of indentation issues.

@nocive awesome - looks good to me.
Last thing: is it feasible to get some test coverage for this?

Sure, also in my plans and in the PR todo checklist :)

@brianr will add it in a few hours, I still need to briefly check the existing test code and figure out where to do it, but I assume it should be fairly quickly. I'm in Berlin tz tho, so it will have to wait for a new day :)

@brianr done, added some basic test coverage mimicking testMessageWithRequestData() method.
Not sure if that's enough or if you guys think something else is needed, let me know.
Also moved php_context to be part of the base data and to be handled in build_base_data() instead.

LGTM. Merging later today with a few other ones for a minor version bump.

@Crisfole awesome, thanks :smiley:

squashed, rdy for merge

Sorry this took so long!

@Crisfole better late than never :)
Thanks guys!


Add new initializations

This PR adds two new initialization methods:

The method from "Understanding the difficulty of training deep feedforward neural networks", Glorot & Bengio, AISTATS 2010. This works very well for sigmoid/tanh activation functions. This is known as the "xavier" initialization in Caffe, where it is the default initialization method for dense layers.

The improvements on the above method made by He et. al, which they showed works much better when using ReLU activation functions.

A few things:

Use float divisions for Python 2.7 compatibility
Activations can potentially be used anywhere, on any input shape, so should not be dependent on the number of dimensions of the input.
I believe the scheme proposed by He is sqrt(2/n_l) where n_l is the number of elements in the layer (n_l = kkc, with k*k the dimensions of the 2D input and c the number of channels).

Silly me for forgetting to include from __future__ import division. You're right, I didn't consider convolutional layers. Should I fix those issues and resubmit or is this something you're not interested in anyhow?

I think these initializations (and in general, more initializations) are definitely valuable to have, of course! If you can generalize them to be shape-agnostic and use float division, that'd be great : )


make xconfig for Linux kernel doesn't display under WSLg

Environment
Windows build number: 21365
Your Distribution version: Debian 11 (bullseye/sid)
Your WSLg version: <IP_ADDRESS>

Steps to reproduce

Clone the WSL Linux Kernel from the Microsoft/WSL2-Linux-Kernel repository, and switch to the linux-msft-wsl-5.10.y branch.
Run make xconfig in the top-level directory cloned repo.

Attach WSLg logs from  /mnt/wslg

You can access the wslg logs using explorer at: \\wsl$\<Distro-Name>\mnt\wslg (e.g.: \\wsl$\Ubuntu-20.04\mnt\wslg)
weston.log
versions.txt
pulseaudio.log
Expected behavior
The kernel configuration utility (i.e., this: https://en.wikipedia.org/wiki/Xconfig ) should be displayed, as per screenshot on right.
Actual behavior
Instead, an empty black window is displayed. The window title appears to be correct, but no contents are visible. The window remains until the configuration utility process is forcibly killed.

@cerebrate do you get some kind of error display? i got the following:
spronovo@OFFICE:~/src/kernel$ make xconfig
*
* Could not find Qt5 via pkg-config.
* Please install Qt5 and make sure it's in PKG_CONFIG_PATH
*
make[1]: *** [scripts/kconfig/Makefile:196: scripts/kconfig/qconf-cfg] Error 1
make: *** [Makefile:602: xconfig] Error 2

After intalling Qt5
sudo apt install qt5*

xconfig worked fine for me.

No, no error message; it just reaches this point:
❯ make xconfig                                                                              2.54  ╱ 6.6G   at 12:40:07 AM  ─╯
  HOSTCC  scripts/kconfig/images.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTCXX scripts/kconfig/qconf.o
  MOC     scripts/kconfig/qconf-moc.cc
  HOSTCXX scripts/kconfig/qconf-moc.o
  HOSTLD  scripts/kconfig/qconf

and stops there indefinitely/until killed.

Hm. That didn't help, but on the other hand, running sudo make xconfig worked immediately. That's not something I've had to do before.

Closing this because it turns out to be a problem with linuxbrew silently breaking the PKG_CONFIG_PATH.


refactor(fscomponents): FLAGSHIP-64 update Shelf to function component

Ticket
https://jira.brandingbrand.com/browse/FLAGSHIP-64
Description
Shelf used to be a class-based component. This PR is to update it to a function component.
Test

run yarn && yarn build:storybook && yarn dev:storybook
navigate to Shelf and then basic usage

Shelf component on the develop branch is already a function component


doc: Question about browserify con

Adds boilerplate code to files (increasing file size and decreasing code readability)

What boilerplate does browserify require in one's code?

Check the first line of this example

Ah! That makes sense. I was thinking in terms of "per-source-file" boilerplate, not in generated output. Thanks.


bin/vendors: new check for git repo, improved error handling and status output

Bugfix: added check whether a dependency directory really is a git repository.
Previously, if it was not git repository but for example an empty directory, "git pull" was not called at all (because directory existed) and "cd  && git fetch origin && git reset --hard %s" subsequently reverted all changes of my project git repository.
More changes:

Improved error handling: check exit code for (most) system() calls.
Print more status information.

Closing as we are now using composer.


Add documentation for DevelopmentDependency

It was missing. Copied the docs from here: https://github.com/NuGet/docs.microsoft.com-nuget/blob/master/docs/reference/nuspec.md
Summary
Describe your changes here.
Fixes #Issue_Number (if available)

@GeertvanHorrik can you please apply @gewarren's suggestion?

Done, sorry, totally missed the suggestion. Note that this is a literal copy/paste from other documentation, you might want to change it on the other location as well to keep things consistent.


Possible incorrect license for zstd-jni

The NOTICE file mentions an optional dependency on zstd-jni.txt, and references LICENSES/zstd-jni.txt . This file includes a copy of the Apache license. However, the NOTICE file points to the original project at https://github.com/luben/zstd-jni and the license there is NOT Apache, but BSD 2-clause (along with a downstream dependency on zstd under BSD or GPL v2.) This is also stated at the bottom of the README file.
Is this a mistake, or did the owner of this project agree to relicense under an Apache license for netty?

This is a mistake

Fixing it...


State Export Logic Audit

Background
If it ever came down to needing a new genesis file for mainnet, we need to be certain that the current state export logic created a genesis file that replicated mainnet 1:1. As it stands, we have had to make many changes over the months after realizing things were left out or were incorrect in osmo-test-4 due to improper state export logic.
Suggested Design
Go through every module and ensure state export logic is sound.
We can even make a new testnet (osmo-test-5) to be the new main testnet, and we can query various things on this testnet and see if there is anything off in terms of what should have been exported and what really was exported.
Acceptance Criteria
Every module has been checked against a running testnet to verify all state export logic is sound.

Unneeded due to in place testnet


Prism-based Syntax Highlighting does not wrap long lines correctly

The HTML rendering engine WinPrint uses (github.com/litehtml) does not support the long-line wrapping features of CSS required by WinPrint. As a result, long lines are not wrapped correctly (or at all).
See https://github.com/litehtml/litehtml/issues/117
Workaround: Use the "text/plain" Content Type Engine by specifying --content-type-engine text/plain  or -e content-type-engine text/plain on the command line. No syntax highlighting, but at least text will wrap correctly.

Addressed via AnsiCte/Pygments.


Feature/60/mouse support

Suggestion for https://github.com/in0rdr/diary/issues/60

I noticed that mouse scroll up/down works in the terminal if I don't catch the mouse events at all.
When scrolling up/down while catching mouse events, I retrieve the following events (event.bstate):
Button event: 65536    <- scrolling up
Button event: 2097152  <- scrolling down

The bstate 4 is actually a left-click..

Discovered some more issues with this approach:

It is no longer possible to select text in vim when the file is opened
Clicking in the "text"/"preview" area will select a random entry at the same height (calendar week)

BUTTON1_PRESSED detects touch events (touch pads)
BUTTON1_CLICKED detects click events (mouse)

double-click now enters edit mode
could not find an event for double-tap (touchpad)


CHANGELOG.md missing entries for v2.0.21-v2.0.26

The last changelog entry is for v2.0.20, whereas the latest released version is v2.0.26.
https://github.com/chef/chef-dk/blob/master/CHANGELOG.md

we know the automatic changelog generator is busted, and that work is being tracked in other (internal) ticketing systems.


Win32Exception thrown while attempting to take screenshot from remote machine

Hi,
I can't provide clear steps to reproduce this issue, but it happens occasionally on the remote machine (never met it while running tests locally). Here is the stacktrace:
   at System.Drawing.Graphics.CopyFromScreen(Int32 sourceX, Int32 sourceY, Int32 destinationX, Int32 destinationY, Size blockRegionSize, CopyPixelOperation copyPixelOperation)
   at canopy.core.takeScreenShotIfAlertUp() in C:\projects\canopy\src\canopy\canopy.fs:line 46
   at canopy.core.takeScreenshot(String directory, String filename) in C:\projects\canopy\src\canopy\canopy.fs:line 60
   at canopy.core.screenshot(String directory, String filename) in C:\projects\canopy\src\canopy\canopy.fs:line 68
   at canopy.runner.fail(Exception ex, String id) in C:\projects\canopy\src\canopy\runner.fs:line 86
   at canopy.runner.runtest$cont@110(suite suite, Test test, Unit unitVar) in C:\projects\canopy\src\canopy\runner.fs:line 123
   at canopy.runner.runtest@105(suite suite, Test test) in C:\projects\canopy\src\canopy\runner.fs:line 110
   at canopy.runner.run@158-5.Invoke(Test w) in C:\projects\canopy\src\canopy\runner.fs:line 158
   at Microsoft.FSharp.Primitives.Basics.List.iter[T](FSharpFunc`2 f, FSharpList`1 x)
   at canopy.runner.run$cont@148(suite s, Unit unitVar) in C:\projects\canopy\src\canopy\runner.fs:line 158
   at canopy.runner.run@145-4.Invoke(suite s) in C:\projects\canopy\src\canopy\runner.fs:line 148
   at Microsoft.FSharp.Primitives.Basics.List.iter[T](FSharpFunc`2 f, FSharpList`1 x)
   at canopy.runner.run() in C:\projects\canopy\src\canopy\runner.fs:line 145
   at Main.main(String[] argv) in d:\jenkins_sits\workspace\Mikz_UITests_Dev\Mikz.AutoTests.Publisher.UI\Program.fs:line 41```

Seems like it happens only when the alert appears on the page? Any ideas how to handle this exception properly?

P.S. I have also found similar problem on [stackoverflow](http://stackoverflow.com/questions/5200341/capture-screen-on-server-desktop-session). But I do not know how other screenshots are taken without problemn on the same remote machine.

Yah that code is in a function called takeScreenShotIfAlertUp  and is an attempt to still take a screen shot even when an alert is up.
Alerts really mess up UI Automation because they are not a part of the DOM.  They are not even an item in your current tab.  They are a part of the browser at the same level/importance as a tab.  They are basically outside of the scope of the actual website.  When a alert is open, Selenium will not a take a screenshot.   That function is an attempt to take a screenshot with Windows calls.
I can try to reproduce the problem locally and improve the function.  Long term, for your own sanity, its probably a good idea work towards removing and avoiding alerts, and using another mechanism for displaying things to your users.

I've thought about this and the best thing I can do is to either
A) not attempt a screenshot if its a remote server
B) Catch any exception and return an empty byte array... which may be the better solution since it will prevent this problem from happening again.
Either one acceptable to you?

I think "B" is better solution, at least for me. Thank you.

hello Chris, have you released the fix? thanks in advance

Sorry for the delay!
https://www.nuget.org/packages/canopy/0.9.43

Thank you, solved my problems.


"ReactComponent" is not exported after update to 4.0.0

Hi! I'm using import { ReactComponent as ArrowDown } from './ArrowDown.svg'. Everything was okay before update to 4.0.0. Now I get an error:
RollupError: "ReactComponent" is not exported by "src/libs/icons/thin/ArrowDown.svg", imported by "src/libs/icons/index.ts".
How can I resolve it?

Can confirm, having the same issue. Reverted to v3.3

I just ran into this as well. Thanks for the tip @Tbaut.
@pd4d10 I see a breaking change on the 4.0.0 releases tag but the only explanation is "Export as default with query" with a link to the commit. It's a little hard to understand the intention of the change as it relates to the named ReactComponent export. Was it a mistake to remove the named export? Or is the only option for accessing the react component going forward to use the default export with the query?

@lnhrdt Hi, sorry, the release log might not be that clear.
Background here: https://github.com/pd4d10/vite-plugin-svgr/pull/71#issuecomment-1727006445

Got it @pd4d10! Thank you for the clarification, and for maintaining this library. 🍻

has anyone got this working in the context of an NX monorepo? Ive got library-a, with a bunch of svg's, imported into a barrel index that is the entry point for the lib thats consumed by app-a. following suggestions mentioned here and it just flat refuses to work

If you are using WebStorm and has a lot of SVG icons to migrate, you can mass-replace all of them with regex mode enabled.
From:
\{ ReactComponent as (.+) } from (.+).svg

To:
$1 from $2.svg?react

has anyone got this working in the context of an NX monorepo? Ive got library-a, with a bunch of svg's, imported into a barrel index that is the entry point for the lib thats consumed by app-a. following suggestions mentioned here and it just flat refuses to work

Did you get this working? I'm having the same issue

Same issue with an nx monorepo, I keep getting errors like:
 >  NX   [vite]: Rollup failed to resolve import "@my-compant/assets/svg/logo.svg?react" from "/Users/me/git/my-project/layout/src/LayoutLogo/LayoutLogo.tsx".

I tried to make a minimum viable repo, but my nx skills are not up to task.

In regards to NX. I think this started failing in commit: 18a4e266478f35e10893045d393825ca5ce11a12
Overriding the include back to what it was seems to be working for me
svgr({ include: '**/*.svg' })


lodestar/cli: overhaul util/version and gitdata

Motivation
Allow for more information in the version string; also clean up util/version and gitdata and reduce duplicated code.
Description

Refactored git data file code and removed some duplicated structures and unused code.
util/gitData/* no longer generates version strings, it just handles all version information (semver, branch, commit, ...)
util/version now generates a proper version string from available data (either from json or from git)

example: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable) (semver/branch/number of commits since last release/commit hash/release track if any)

util/version now defines a default release track (stability), for now: alpha
cli/cli improved top banner of the --help output and also used same information for --version

~/.opt/chainsafe/lodestar q9-yarn-semver
❯ ./lodestar --version
🌟 Lodestar: TypeScript Implementation of the Ethereum 2.0 Beacon Chain.
  * Version: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable)
  * by ChainSafe Systems, 2018-2021

~/.opt/chainsafe/lodestar q9-yarn-semver
❯ ./lodestar --help
🌟 Lodestar: TypeScript Implementation of the Ethereum 2.0 Beacon Chain.
  * Version: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable)
  * by ChainSafe Systems, 2018-2021

Commands:
  beacon             Run a beacon chain node
  validator          Run one or multiple validator clients
  account <command>  Utilities for generating and managing Ethereum 2.0 accounts
  init               Initialize Lodestar directories and files necessary to run
                     a beacon chain node. This step is not required, and should
                     only be used to prepare special configurations
  dev                Quickly bootstrap a beacon node and multiple validators.
                     Use for development and testing

Options:
      --rootDir     Lodestar root directory                             [string]
      --network     Name of the Eth2 chain network to join
           [string] [choices: "mainnet", "pyrmont", "prater", "altair-devnet-3"]
                                                            [default: "mainnet"]
      --preset      Specifies the default eth2 spec type
                   [string] [choices: "mainnet", "minimal"] [default: "mainnet"]
      --paramsFile  Network configuration file
                                        [string] [default: $rootDir/config.yaml]
  -h, --help        Show help                                          [boolean]
  -v, --version     Show version number                                [boolean]

📖 For more information, check the CLI reference:
  * https://chainsafe.github.io/lodestar/reference/cli

✍ Give feedback and report issues on GitHub:
  * https://github.com/ChainSafe/lodestar

The code also handles the logic of releases and dirty/nightly builds. A release version string is simply v0.28.1 (alpha) whereas dirty builds have all info v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable). If git data is not available, it will fall back to lerna.json/package.json and just use 0.28.1.
This is my first typescript contribution. Review with care. 🙏🏼
Fixes #2950

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I would appreciate if we can make a test point release (v0.28.2) if this is good to go.

Ok, fixed the linter issues, this should be good to go.

Sorry, fixed one minor logic issue. Now it's good to go.

Thanks for the review. The logic around gitData was not changed and should be still available. Do you mean, we should expose branch and commit on the metrics even though it's usually a tag release? Metrics is the only place where I changed it for simplicity but happy to add back more details.

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 :+1:

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 +1

I just checked, the nighly release version is 0.28.2-dev.3+022659b5fc0 according to Github actions (appending the --canary git sha option) but the NPM registry just truncates everything after the + to strict (?) semver and it just remains 0.28.2-dev.3. I found this: https://github.com/lerna/lerna/issues/1893

Association with the current NPM versions is very hard. If the published version is<EMAIL_ADDRESS>I have to count 124 commits up from 0.1.4 or go through CI logs to figure out which commit that version is tied to. If it were<EMAIL_ADDRESS>or<EMAIL_ADDRESS>it would be much easier.
It looks like Lerna is publishing with the +${sha} suffix, but it seems NPM is stripping it out. If that's the case, why is this format not configurable?

At first glance, there seems no easy way to force lerna to do that properly.

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 +1

I just checked, the nighly release version is 0.28.2-dev.3+022659b5fc0 according to Github actions (appending the --canary git sha option) but the NPM registry just truncates everything after the + to strict (?) semver and it just remains 0.28.2-dev.3. I found this: lerna/lerna#1893

Association with the current NPM versions is very hard. If the published version is<EMAIL_ADDRESS>I have to count 124 commits up from 0.1.4 or go through CI logs to figure out which commit that version is tied to. If it were<EMAIL_ADDRESS>or<EMAIL_ADDRESS>it would be much easier.
It looks like Lerna is publishing with the +${sha} suffix, but it seems NPM is stripping it out. If that's the case, why is this format not configurable?

At first glance, there seems no easy way to force lerna to do that properly.

What if we write our own version format? Not use any counter at all and only the commit hash:
0.28.2-dev.022659b5fc0


packaging: add native debian package

For development purposes, add native debian packaging.

Add build-deb.sh to /scripts/

Add debian package metadata to /packaging/debian

Add a starter manpage to /doc in markdown format, using pandoc to convert to manpage.

Add github workflow to validate debs.

Move azure-nvme-id.spec to /packaging/azurelinux.  It may work for other RPM distros too, but will revisit structure upon validating Fedora, etc.

lintian detects the following warnings from groff on sid:
W: azure-nvme-utils: groff-message troff:<standard input>:50: warning: cannot select font 'C' [usr/share/man/man1/azure-nvme-id.1.gz:2]
W: azure-nvme-utils: groff-message troff:<standard input>:5: warning: cannot select font 'CB' [usr/share/man/man1/azure-nvme-id.1.gz:1]
W: azure-nvme-utils: groff-message troff:<standard input>:60: warning: cannot select font 'C' [usr/share/man/man1/azure-nvme-id.1.gz:3]
W: azure-nvme-utils: groff-message troff:<standard input>:72: warning: cannot select font 'C' [usr/share/man/man1/azure-nvme-id.1.gz:4]

This appears to be a pandoc issue and may be fixed upstream. I'm not sure if this can be worked around in the input file or not, but it's probably worth a try. You can see the warnings yourself with
$ man -l obj-x86_64-linux-gnu/doc/azure-nvme-id.1  > /dev/null
troff:<standard input>:5: warning: cannot select font 'CB'
troff:<standard input>:50: warning: cannot select font 'C'
troff:<standard input>:60: warning: cannot select font 'C'
troff:<standard input>:72: warning: cannot select font 'C'

Addressing with https://github.com/Azure/azure-nvme-utils/pull/27

Any reason not to squash cc097bc ("fix description in debian/control") into 49e60b6 ("packaging: add native debian package")?

Squashed. Sometimes I try to be github-review-friendly and squash on merge. :)


Want to improve the  New Post section [OTHER]

What would you like to share?
I want to improve the new post section  UI to improve the user experience

Additional information
No response

you're already assigned an issue, please fix that first!

what'd you change in this section?

you're already assigned an issue so you can not be assigned before completing that @HimanshuNarware .

ok

what'd you change in this section?

Want  to improve the UI of this section


This may be because of the amount of damage melee weapons simply cause, however, I have been thinking about going about myself and making a balancing mod or pull request.

This was caused by the bhaptics integration mod and not Fusion


feat(PeriphDrivers): Add Ability to Set UART Pin Mapping for MAX32672

Description
Closes #733
Adds MXC_UART_SetPinMapping and MXC_UART_GetPinMapping for the MAX32672, and pin definitions to pins_me21.c.
Setter should be called before UART_Init...
MXC_UART_SetPinMapping(MXC_UART0, MAP_B);
MXC_UART_Init(MXC_UART0, ...);
// ...

Also fixed UART2A mapping being incorrect.  It was pointing to UART2B...
Checklist Before Requesting Review

[ ] PR Title follows correct guidelines.
[ ] Description of changes and all other relevant information.
[ ] (Optional) Link any related GitHub issues using a keyword
[ ] (Optional) Provide info on any relevant functional testing/validation.  For API changes or significant features, this is not optional.

Merge from main, should fix the Verify Register/SVD workflow.


test: Add rawkv empty key/value test

Signed-off-by: haojinming<EMAIL_ADDRESS>
What is changed and how it works?

Issue Number: Close #13635
What's Changed:

Add rawkv empty key/value test

Related changes
Check List
Tests

Unit test

Side effects
Release note
None.

/merge

/test


increment version

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/97646
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.6 -m "<description of version>" f37df37e8ac383361a0fc71484770d60ae69771d
git push origin v0.1.6


Reading attribute failed with chip-device-ctrl but succeeded with chip-tool

Problem
./chip-tool threadnetworkdiagnostics read network-name 0
[1623993584.244237][1614665] CHIP:IN: Secure message was encrypted: Msg ID 9
[1623993584.244241][1614665] CHIP:IN: Encrypted message 0x55e9e67dd800 from 0x000000000001B669 to 0x0000000000BC5C01 of type 1 and protocolId 9 on exchange 39017.
[1623993584.244245][1614665] CHIP:IN: Sending msg 0x55e9e67dd800 to 0x0000000000BC5C01 at utc time: 540796789 msec
[1623993584.244249][1614665] CHIP:IN: Sending secure msg on generic transport
[1623993584.244297][1614665] CHIP:IN: Secure msg send status No Error
[1623993584.244303][1614665] CHIP:CTL: SendMessage returned No Error
[1623993584.304725][1614672] CHIP:IN: Secure transport received message destined to fabric 0, node 0x000000000001B669. Key ID 0
[1623993584.304760][1614672] CHIP:EM: Received message of type 2 and protocolId 9 on exchange 39017
[1623993584.304770][1614672] CHIP:EM: Rxd Ack; Removing MsgId:00000009 from Retrans Table
[1623993584.304787][1614672] CHIP:EM: Removed CHIP MsgId:00000009 from RetransTable
[1623993584.304819][1614672] CHIP:ZCL: APS frame processing success!
[1623993584.304823][1614672] CHIP:ZCL: RX len 8, ep 1, clus 0x35
[1623993584.304826][1614672] CHIP:ZCL:  FC 8 seq 0 cmd 1 payload[
[1623993584.304832][1614672] CHIP:ZCL: 02 00 00 41 00
[1623993584.304834][1614672] CHIP:ZCL: ]
[1623993584.304840][1614672] CHIP:ZCL: ReadAttributesResponse:
[1623993584.304843][1614672] CHIP:ZCL:   ClusterId: 0x0035
[1623993584.304846][1614672] CHIP:ZCL:   attributeId: 0x0002
[1623993584.304849][1614672] CHIP:ZCL:   status: EMBER_ZCL_STATUS_SUCCESS (0x00)
[1623993584.304852][1614672] CHIP:ZCL:   attributeType: 0x41
[1623993584.304857][1614672] CHIP:ZCL:   value:
[1623993584.304861][1614672] CHIP:TOO: String attribute Response: 0
[1623993584.304869][1614672] CHIP:ZCL: Data model processing success!
chip-device-ctrl > zclread ThreadNetworkDiagnostics NetworkName 12344321 1 0
[1623993288.186294][1511887] CHIP:IN: Encrypted message 0x16bb3c0 from 0x000000000001B669 to 0x0000000000BC5C01 of type 1 and protocolId 9 on exchange 39033.
[1623993288.186312][1511887] CHIP:IN: Sending msg 0x16bb3c0 to 0x0000000000BC5C01 at utc time: 540500731 msec
[1623993288.186317][1511887] CHIP:IN: Sending secure msg on generic transport
[1623993288.186391][1511887] CHIP:IN: Secure msg send status No Error
[1623993288.397213][1511895] CHIP:IN: Secure transport received message destined to fabric 0, node 0x000000000001B669. Key ID 0
[1623993288.397281][1511895] CHIP:EM: Received message of type 2 and protocolId 9 on exchange 39033
[1623993288.397328][1511895] CHIP:ZCL: RX len 6, ep 1, clus 0x35
[1623993288.397331][1511895] CHIP:ZCL:  FC 8 seq 8 cmd 1 payload[
[1623993288.397335][1511895] CHIP:ZCL: 02 00 86
[1623993288.397337][1511895] CHIP:ZCL: ]
[1623993288.397341][1511895] CHIP:ZCL: ReadAttributesResponse:
[1623993288.397345][1511895] CHIP:ZCL:   ClusterId: 0x0035
[1623993288.397350][1511895] CHIP:ZCL:   attributeId: 0x0002
[1623993288.397353][1511895] CHIP:ZCL:   status: EMBER_ZCL_STATUS_UNSUPPORTED_ATTRIBUTE (0x86)
Failed to establish secure session to device: 134
An exception occurred during reading ZCL attribute:
[1623993288.397486][1511895] CHIP:IN: Encrypted message 0x7f5d52ffc490 from 0x000000000001B669 to 0x0000000000BC5C01 of type 16 and protocolId 0 on exchange 39033.
Error 134 (0x00000086)
[1623993288.397496][1511895] CHIP:IN: Sending msg 0x7f5d52ffc490 to 0x0000000000BC5C01 at utc time: 540500942 msec
[1623993288.397500][1511895] CHIP:IN: Sending secure msg on generic transport
[1623993288.397529][1511895] CHIP:IN: Secure msg send status No Error
Proposed Solution
<suggested fix, suggested enhancement>

Reading on wrong endpoint


Factorise library + add spec templates

From what I can see, there's a lot of scrappy code in the library. It has 0 test coverage and that needs to go to 100%. I don't think I'll have the time to do that, but I've put it in a state far better than what it is and hopefully y'all can improve on it.
<3 Mondo. Gutted I won't be able to make it to the hackathon in a couple of weeks :(

Bump


drawPixmap(): resizing not correct

The drawPixmap() overload that resizes the src rect does not yield the correct result. I use the following code to make a pixmap half the original resolution:
Pixmap temp = new Pixmap(pixmap.getWidth() / 2, pixmap.getHeight() / 2, pixmap.getFormat());
temp.drawPixmap(pixmap, 0, 0, pixmap.getWidth(), pixmap.getHeight(), 0, 0, temp.getWidth(), temp.getHeight());
This is the scene with the original images:

If I resize the images with the code above, the result is the following:

If you download both images and switch between them in any image viewer, you can see that the resized objects are moving towards the lower-right corner of the screen. With my sprite sheet animation, the effect is clearly visible, with every animation step, the character moves more to the right.

Could you try the following:
Pixmap temp = new Pixmap(pixmap.getWidth() / 2, pixmap.getHeight() / 2, pixmap.getFormat()); temp.drawPixmap(pixmap, 0, 0, pixmap.getWidth(), pixmap.getHeight(), 0, 0, temp.getWidth() - 1, temp.getHeight() - 1);
Pixmap coords origin is in the top left so providing a target rectangle that is too big would result in everything being slightly shifted to the bottom right.

That made it a little better, some grass tiles still move, some don't move anymore (they are all in the same texture). But is it logical? Why is the result not the same like when I resize the image with GIMP?
Also, I noted that the smaller image is darker. I think this may have to do with that the background is black alpha and that it creeps into the borders when resizing.

You shouldn't have to subtract 1 from the width and height of the destination. That suggests that there is something wrong in the scaling code.

Please provide a compiling ApplicationListener that illustrates the problem. Will reopen in that case.

Here you are:
import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.Pixmap;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class MyApplication implements ApplicationListener {
    @Override
    public void create() {
        sprite = new SpriteBatch();
        test = new Texture("test.png");

        Pixmap src = new Pixmap(Gdx.files.internal("test.png"));
        Pixmap dest = new Pixmap(src.getWidth() / 2, src.getHeight() / 2, src.getFormat());
        dest.drawPixmap(src, 0, 0, src.getWidth(), src.getHeight(), 0, 0, dest.getWidth(), dest.getHeight());
        test_resized = new Texture(dest);
    }

    @Override
    public void dispose() {
    }

    @Override
    public void resize(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }

    @Override
    public void render() {
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

        sprite.begin();
        sprite.draw(test, 0, 0, width / 2, height);
        sprite.draw(test_resized, width / 2, 0, width / 2, height);
        sprite.end();
    }

    private SpriteBatch sprite;
    private Texture test;
    private Texture test_resized;
    private int width;
    private int height;
}

This is what the application displays:

The left half of the screen is the original texture and the right one is the scaled version. You can clearly see that the right half is shifted to the lower right corner.
Here is the texture "test.png" so that you can try it for yourself (put to android/assets):

Let me know if I can help more. I would have actually fixed it myself, if the bug were on the Java side.

I might have a work around for this problem.
Instead of rendering with a SpriteBatch, use a Sprite and it's scale function.
So, that would look something like this:
Sprite sprite = new Sprite(new Texture(src));
sprite.setScale(0.5f);
// set position and whatnot
then in render:
sprite.draw(yourSpriteBatch);
I have tested this solution in my own application with a scale down to 0.1f


Don't break JS if user agent is empty

I might be wrong, but if I interpret the output of my local JS console correctly, the browser variable can be null (when the user agent string is not present) which leads to a
// browser = null
// browser[2]
TypeError: browser is null

Which causes all JS to halt.
Can anyone confirm that?

Closing due to inactivity.


chore(typings): fix typo in api-list.component.spec.ts

Description:
Small typo fix in api-list.component.spec.ts.

I've created a new PR (Previous #4255) because the original commit wasn't in a separate branch, as required by the guidelines.

Pull Request Test Coverage Report for Build 7500

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.806%

Totals

Change from base Build 7485:
0.0%

Covered Lines:
5244

Relevant Lines:
5417

💛  - Coveralls


make it easy to track e2e test performance over time

Description of Problem:
It is challenging to track how end-to-end tests are performing over time
Overview of the Solution:
"The ability to generate junit.xml files for some of the nlu / e2e story tests. The nlu test generates a json file which can be consumed by our pipeline, but the results of the e2e tests only show the errors in the failed_stories.md file. I’m not tied to junit.xml files, json generated results are fine as well, but would be a good way for us to plot and keep track of how our tests are performing. Happy to chat further about this or put a ticket into the github repo, just thought I’d run it past you first to see if you know if this is something that is in the pipeline"
This is from a user. I am going to chat with them further about this to better understand their workflow

@RasaHQ/production-squad  can we deprio this?

@wochinge I want to talk to the user more first. I think I would make case that this would help enterprises use end-to-end tests more

@TyDunn ok, just checked. It would be just writing the return dictionary of https://github.com/RasaHQ/rasa/blob/26f78e845507d2e3a6a83ff75edd28687d3e8510/rasa/core/test.py#L557 to disk.

NLU test json output:
DIETClassifier_errors.json - entity classification errors
DIETClassifier_report.json - entity extraction f1, precision, recall summary
intent_errors.json - intent error details
intent_report.json - intent precision
RegexEntityExtractor_errors.json - errors
RegexEntityExtractor_report.json - details
Story json output:
story_report.json - precision

Customer brought this issue up so adding it to CSE board

closing as stale


Automate more things

Any idea what should be done on the automation front?

https://github.com/ahmia/search/issues/25 and https://github.com/ahmia/search/issues/26 are automation tasks too (on the project side of things).

Continuous integration is done with travis.CI. I plan to use it with tests (to discover bugs, regressions) and pylint (to make sure we push code with good quality).
Code quality tracking is done with landscape.io (example).
Requirements tracking is done with requirements.io (example).


Support .env files

Support .env files in order to load configurations into ENV variables.
This is a well known and large used best practice.
This is a proposal to support multiple environments and put those files under config/. We should have a general file .env that is the master of all the configurations. Then we should have per environment settings.
# ...
config/
  .env             # general
  .env.development # environment specifics overloads
  .env.test

The idea is to use a dotenv gem for this.
Example
# config/.env.development
DATABASE_URL="postgres://localhost/bookshelf_development"

# config/.env.test
DATABASE_URL="postgres://localhost/bookshelf_test"

module Bookshelf
  class Application < Lotus::Application
    configure do
      adapter type: :sql, uri: ENV['DATABASE_URL']
    end
  end
end

I know that it is already merged but just to reconsider the topic I'll propose another approach - ENVied. The only thing it does is to "eat" the ENV but with coercion (no more problems to handle booleans) and setting required keys (so app won't start until all required keys are there).
And it's up to dev how it populate the ENV which is fine - one will use rbenv-vars, others dotenv or anything else.

@jandudulski Thanks for your suggestion but I don't think it's a good idea.
Dotenv, uses a UNIX compatible syntax. This makes applications deployable in all the contexts and we could decide to bypass it entirely if the server will load .env before the application is started.
UNIX standards > Ruby DSLs.
Another point is that about dependencies: Dotenv doesn't have runtime dependencies. ENVied will bring: coercible, descendants_tracker and thread_safe.

The issue is that dotenv and ENVied resolves two different problems.
dotenv loads variables from the file into the ENV
ENVied allows you to setup list of required variables to been setup in the application and coerce to types. And I think that framework itself shoudn't care how to populate ENV but how to handle it.


CoreFoundation -[NSInvocation retainArguments].cold.1

I used multiple images to load in the cell, and a crash occurred！
Alamofire Environment
Alamofire Version:
PODS:

Alamofire (5.2.1)
AlamofireImage (4.1.0):

Alamofire (~> 5.1)
Dependency Manager: Cocoapods
Xcode Version: 12.3
Swift Version:  swift5
Platform(s) Running Alamofire: iOS

Demo Project
self.imageView.af.setImage(withURL: url,placeholderImage: UIImage.init(named: "placeholderImage"))
ℹ Please link to or upload a project we can download that reproduces the issue.

This is an AlamofireImage issue caused by trying to decode images which are too large to fit into the device's memory. I suggest you resize them or follow the workaround directions in that issue.


"Surprised" emoji can't be downloaded as lottie/webp/gif

Expected behavior

I can download the :surprised: emoji in gif/lottie or webp at: https://googlefonts.github.io/noto-emoji-animation/?icon.query=:surprised:

Actual behavior

Link seems to be broken and doesn't trigger any download unlike any other emojis

Good catch ! Hope that it will be fixed rapidly :)

Apologies for both the issue and slow response. I believe https://github.com/googlefonts/emoji-metadata mistakenly reported that emoji as animated. Fixed by https://github.com/googlefonts/emoji-metadata/pull/52.


answer this question please

could you please answer @mbadolato question here in the link but answer it in this github thread
https://gist.github.com/wjzijderveld/dcd9a6478346182b287a
thanks cc @wjzijderveld

i think i found the related explanation sort of here https://github.com/qandidate-labs/broadway/issues/109#issuecomment-68335644 onwards.

No, those are two completely unrelated things. #109 was discussing the indexing and non-analyzed fields for Elasticsearch. The gist is asking about logic in a sample piece of code used to actually generate an index for one specific model (as opposed to all indexes)

Commented:
We extend the ElasticsearchRepository for most of our repositories.
For repositories using the factory it won't work :disappointed:

Got it, thanks!

hmm how is the extended class of the ElasticsearchRepository of yours look like that it solves the issue @mbadolato referred to? just curious. :baby: and for completeness sake. I will close but if you happen to be of a good heart you can paste the gist. Thanks!

The extended classes are usually just a constructor that define some of the
arguments for the base class.
And sometimes a method to do a specific query for that read model.
On 2 Feb 2015 03:55, "Luis Cordova"<EMAIL_ADDRESS>wrote:

hmm how is the extended class of the ElasticsearchRepository of yours look
like that it solves the issue @mbadolato https://github.com/mbadolato
referred to? just curious. [image: :baby:] and for completeness sake. I
will close but if you happen to be of a good heart you can paste the gist.
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/qandidate-labs/broadway/issues/131#issuecomment-72400482
.


feat: Rarity classification type explanation modal

The type of this PR is: Feature

This PR resolves CX-2202
Description
This PR helps in displaying a modal having rarity types and their explanations by tapping on What is this?

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Rarity classification explanation modal tapping on What is this? - sam

iOS user-facing changes

Android user-facing changes

Dev changes

This PR contains the following changes:

Cross-platform user-facing changes (Rarity classification explanation modal tapping on What is this? - sam)

  Generated by :no_entry_sign: dangerJS against 8ff38f126b1460b3be5cd9bde42de2dc13e24261

#squashongreen


Bump to Dojo V1.0.1

@tevrat-aksoy Please bump to Dojo 1.0.1 and also delete CardKnight-FE submodule to resolve the conflict


Predicted scores and visualisations on the front end

Hi. Nice work on the project.
Are you interested in working towards some  visualisation stuff (chart.js or D3) and predictive analytics (descriptive statistics, predicted scores, etc.)?

Hi @raunak-agarwal, yeah adding some descriptive and predictive viz would be a good idea.