[WG Platforms] Platforms Def - What is a platform

Review and finalize "What is a platform" section of Platforms whitepaper: https://github.com/cncf/tag-app-delivery/blob/platforms-v1alpha1/platforms-whitepaper/v1alpha1/paper.md#what-is-a-platform

@joshgav it'd be great to potentially own this section if possible would love to add some details here as well as helping solicit feedback let me know if that works!

Thank you @abhinavm-rafay, that would be great, I went ahead and assigned you here; we can add others if appropriate.
As we chatted, let's try making significant edits via PRs to the platforms-v1alpha1 branch, and having discussions here or in distinct issues as you feel appropriate. Thank you!

It seems like we have some doubts about the naming. We opted for talking about "platforms" in general, but as also understandable from Matthew Skelton's comment, that term is too generic and we probably need to be more specific.

Therefore, an "application platform" (or "internal developer platform/IDP") would be a type of cloud native platform that supports the path to deliver value to the application end-users, from idea to production. But there are more.
Other types of cloud native platforms would be:

core platform (containing only the services necessary to offer a Kubernetes-based environment with security, compliance and access control that could provide the foundation to build special-purpose platforms on top of it).
deployment platform (focused on the final part of the path to production)
data platform (oriented to big data or ML use cases)
observability platform (offering services to monitor, visualize, and work with telemetry and other signals coming from different sources, including other platforms).

I wonder if an "application platform" (which supports the path to deliver value to the application end-users, from idea to production) consists of a deployment platform and observability platform? The path from idea to production always needs deployment and observability, isn't it?

These categories are not standard terminology, so I wouldn't try to use them here. At least, not in this first paper. I would talk more in general about "cloud native platforms" with focus on how we build them, both from a technical and an organisational point of view, and how to provide the best user experience. I'm not a fan of the "developer platform" terminology because application developers are not the only users of the platform. I think that the UX is critical for all users of the platform.

Totally agree, we also had platform users who hosted third-party applications on our platform, but they weren't developers. Although they used the same APIs (gitops-repos, gitlab-pipelines) to deploy there applications on the platform. However, they didn't develop the applications by themselves.
What do you think about the term "container platform"?

Just raising my hand to help here 👍

I'd like to add the Pulumi name & logo for the diagram in this section, likely best fitting in "provide environments and resources". In addition to being a CLI, Pulumi has the Automation API, an SDK to allow platform teams to integrate provisioning in their services, and a Kubernetes operator for provisioning via programs defined as k8s resources in YAML.
I can make a PR to add to the table under #279, however the image is a blob and I don't want to race anyone on trying to edit the diagram in Google Docs.

It seems like we have some doubts about the naming. We opted for talking about "platforms" in general, but as also understandable from Matthew Skelton's comment, that term is too generic and we probably need to be more specific.

Therefore, an "application platform" (or "internal developer platform/IDP") would be a type of cloud native platform that supports the path to deliver value to the application end-users, from idea to production. But there are more.
Other types of cloud native platforms would be:

core platform (containing only the services necessary to offer a Kubernetes-based environment with security, compliance and access control that could provide the foundation to build special-purpose platforms on top of it).
deployment platform (focused on the final part of the path to production)
data platform (oriented to big data or ML use cases)
observability platform (offering services to monitor, visualize, and work with telemetry and other signals coming from different sources, including other platforms).

I wonder if an "application platform" (which supports the path to deliver value to the application end-users, from idea to production) consists of a deployment platform and observability platform? The path from idea to production always needs deployment and observability, isn't it?

I also see an "application platform" as one that comprises all the necessary capabilities to go from idea to production. But I wouldn't define it in terms of a combination of other platform types. In general, I see a "pool" of capabilities that are composed together to achieve a well defined goal. What capabilities to include depends on what we are trying to achieve. Which is why I wouldn't focus too much on platform types, besides providing examples.

These categories are not standard terminology, so I wouldn't try to use them here. At least, not in this first paper. I would talk more in general about "cloud native platforms" with focus on how we build them, both from a technical and an organisational point of view, and how to provide the best user experience. I'm not a fan of the "developer platform" terminology because application developers are not the only users of the platform. I think that the UX is critical for all users of the platform.

Totally agree, we also had platform users who hosted third-party applications on our platform, but they weren't developers. Although they used the same APIs (gitops-repos, gitlab-pipelines) to deploy there applications on the platform. However, they didn't develop the applications by themselves.
What do you think about the term "container platform"?

I see "container platform" as a type of cloud native platforms. Perhaps one I could use as a developer to provide a pre-built container image, and then the platform takes care of the rest. But I wouldn't expect the platform to take care of provisioning databases on Azure (just to make an example), or to take care of supporting the entire software supply chain, or to provide a temporary development environment. But that is a very subjective description, which is one of the reasons why I prefer focusing more on the general architectural style ("cloud native") and the several capabilities that might be part of the final product (in a flexible and composable fashion).

Looking for thoughts and opinions of others on this, To build a platform that can offer services to thousands of customers, cloud providers have an underlying control plane that ensures the desired state of infrastructure that a customer has requested is aligned with the actual state.
If they are not already, the control plane will work to drive the two states to alignment. In simplest terms, the control plane is what translates from the interface exposed to users to actions required to satisfy their requests. A platform is an API that the control plane exposes. A lot of companies like Upbound and many others, here's how to drive the conversation, and here's how they think about the platform, looking for opinions do you think these sentences and terms fall under the definition, if yes, I'm thinking we can drive a similar story forward.

@AaronFriel, we're working on a different place to include examples and other resources. (cc'ing @joshgav)
Can you please move your request into the Capabilities section? https://github.com/cncf/tag-app-delivery/issues/279

Similarly, I like talking about "cloud native platforms" as an architectural style to design and implement platforms that thrive in cloud environments (but they don't have to necessarily run there). That architectural style could be applied to support multiple use cases resulting in different categories of platforms, all sharing the same architectural principles and properties (the ones listed in the paper as "key attributes").

Hi @ThomasVitale
I agree with this as well. The problem is if we get too broad it might not be as impactful for those who are adopting cloud native technologies and need some guidance on what direction to go in. The goal is to provide a clear pathway for those enterprises and companies who have adopted data center/cloud technologies today and are transitioning to building platforms via cloud-native but need some guidance.
@joshgav Any thoughts here?

Looking for thoughts and opinions of others on this, To build a platform that can offer services to thousands of customers, cloud providers have an underlying control plane that ensures the desired state of infrastructure that a customer has requested is aligned with the actual state.
If they are not already, the control plane will work to drive the two states to alignment. In simplest terms, the control plane is what translates from the interface exposed to users to actions required to satisfy their requests. A platform is an API that the control plane exposes. A lot of companies like Upbound and many others, here's how to drive the conversation, and here's how they think about the platform, looking for opinions do you think these sentences and terms fall under the definition, if yes, I'm thinking we can drive a similar story forward.

@Saim-Safdar Agreed on this and this kind of ties in with thomas's comment as well. there is an intended desired state that developers request for and some underlying component/control plane that takes care of this in terms of reconciliation and operations. Not all of this can be delegated simply to the cloud provider because there are other things that need taking care of for example authentication or invoking APIs across multiple cloud platforms to deploy the entire app stack.

Similarly, I like talking about "cloud native platforms" as an architectural style to design and implement platforms that thrive in cloud environments (but they don't have to necessarily run there). That architectural style could be applied to support multiple use cases resulting in different categories of platforms, all sharing the same architectural principles and properties (the ones listed in the paper as "key attributes").

Hi @ThomasVitale
I agree with this as well. The problem is if we get too broad it might not be as impactful for those who are adopting cloud native technologies and need some guidance on what direction to go in. The goal is to provide a clear pathway for those enterprises and companies who have adopted data center/cloud technologies today and are transitioning to building platforms via cloud-native but need some guidance.
@joshgav Any thoughts here?

Yeah, I agree that it's important to give some concrete examples to make it clear to the reader.

Looking for thoughts and opinions of others on this, To build a platform that can offer services to thousands of customers, cloud providers have an underlying control plane that ensures the desired state of infrastructure that a customer has requested is aligned with the actual state.
If they are not already, the control plane will work to drive the two states to alignment. In simplest terms, the control plane is what translates from the interface exposed to users to actions required to satisfy their requests. A platform is an API that the control plane exposes. A lot of companies like Upbound and many others, here's how to drive the conversation, and here's how they think about the platform, looking for opinions do you think these sentences and terms fall under the definition, if yes, I'm thinking we can drive a similar story forward.

@Saim-Safdar Agreed on this and this kind of ties in with thomas's comment as well. there is an intended desired state that developers request for and some underlying component/control plane that takes care of this in terms of reconciliation and operations. Not all of this can be delegated simply to the cloud provider because there are other things that need taking care of for example authentication or invoking APIs across multiple cloud platforms to deploy the entire app stack.

That's a very good point and an important aspect we could elaborate later in the document (perhaps "attributes of platforms"?). Having the platform as a "universal control plane" makes it possible to manage any tool in a consistent and unified way (either running on k8s or externally), while still allowing flexibility to organisations that don't have to go through a big-bang migration but can proceed in small steps and continue using existing tools they spent a lot of money to establish over the years. With the different being that they are integrated with the platform for unified management and control. I really like how Victor Farcic (Upbound) explains this concept in this episode of his show: https://www.youtube.com/watch?v=j5i00z3QXyU

Lots of great thoughts and progress here!
A couple of quick opinions from me:
There is lots of chatter in general in the other issues and slack around examples that are "platforms as a product" and I believe this paper should be focused on helping to point out problems, approaches, and solutions experienced by people, etc, not necessarily what a platform should look/function like. It's up to the products themselves to define the user experience and how they solve problems in their own unique ways, and to what depth.  Those are the same decisions these teams will make when they start developing their own platforms.
To me, the platform is the (almost literal) sandbox that teams play in together to get work done. It's the tangible place folks can go get the information they need, create the resources they need, operate within guardrails, etc, in ways that also fit the business requirements. Not a "one PaaS that rules them all", but an understood collection of tools that work together.
While this isn't a maturity model, and maybe it will grow into one in the future, there should be flexibility in the definition of a platform to make it so it doesn't require 'doing all the things' as some sort of conformance for being a platform.

@ThomasVitale

I would talk more in general about "cloud native platforms" with focus on how we build them, both from a technical and an organisational point of view, and how to provide the best user experience. I'm not a fan of the "developer platform" terminology because application developers are not the only users of the platform.

I like talking about "cloud native platforms" as an architectural style to design and implement platforms that thrive in cloud environments (but they don't have to necessarily run there). That architectural style could be applied to support multiple use cases resulting in different categories of platforms, all sharing the same architectural principles and properties (the ones listed in the paper as "key attributes").

:heart:
I also prefer to call these platforms "cloud" or "cloud-native" platforms, and I also think "cloud" or "cloud-native" is a new architectural style enabled by such platforms. I wrote about it a while ago FWIW: https://blog.joshgav.com/posts/cloud-redefined-infrastructure
IMO "developer" is a bit of a distraction as the value of a cloud platform is mostly in accelerating delivery of value and that doesn't have to involve application developers - think of commercial-off-the-shelf (COTS) software operators, data scientists, information workers, etc. An overemphasis on developers may also be questioned by enterprise leaders.
It has led to heated discussion when an adjective is proposed, and so in fact that's why the WG is just called "Platforms" :laughing:. But I think we might be able to get consensus on "cloud-native platforms" - after all we're developing this as the "cloud-native computing foundation".
@ThomasVitale

In general, I see a "pool" of capabilities that are composed together to achieve a well defined goal. What capabilities to include depends on what we are trying to achieve. Which is why I wouldn't focus too much on platform types, besides providing examples.

Other types of cloud native platforms would be:

core platform (containing only the services necessary to offer a Kubernetes-based environment with security, compliance and access control that could provide the foundation to build special-purpose platforms on top of it).
deployment platform (focused on the final part of the path to production)
data platform (oriented to big data or ML use cases)
observability platform (offering services to monitor, visualize, and work with telemetry and other signals coming from different sources, including other platforms).

@abhinavm-rafay

The problem is if we get too broad it might not be as impactful for those who are adopting cloud native technologies and need some guidance on what direction to go in.

How about we list these "types of platforms" as use cases in the "Why are platforms valuable" section?
We would describe the core notion of cloud-native platforms as collections of integrateable capabilities first, then describe specific sets of such capabilities for particular use cases next.

@jkleinlercher

What do you think about the term "container platform"?

Overcoming the notion of a container "platform" may in fact be part of the reason to publish this paper :laughing:. That is, containers are interesting but they're just one form of compute in a broad platform of capabilities; there are other forms of compute and other capabilities required to build cloud-native apps. Just to illustrate, an enterprise could adopt a build-from-source-oriented compute paradigm using e.g. Knative and hide containers from developers.
@Saim-Safdar

cloud providers have an underlying control plane that ensures the desired state of infrastructure that a customer has requested is aligned with the actual state

Yes! I agree that this is the implementation of a platform many of us believe in, and not coincidentally Kubernetes' controller-manager (or "operator") framework embodies it. FWIW I wrote about that here: https://blog.joshgav.com/posts/kubernetes-isnt-about-containers.
I'm not sure I'd go so far as to say a reconciliation-oriented approach is required for a platform though. For example, some folks may prefer to imperatively run Terraform commands. I think the top-level requirement is to choose and implement consistent interfaces to a complete set of capabilities in some way that fits the needs of the organization and platform users.
Thoughts?

@joshgav I like the idea of the types of platforms
I think we should also think about this from a persona point of view. We have builders and consumers. The builders are typically platform admins. Users can be a developer but can be anybody including platform users or other types of admins themselves. They could be doing security, fin ops, anything.
I think for the paper it should be giving them direction in terms of

what are the pain points today - stitching disparate solutions, not able to create self-service models across your org for different personas, not able to launch new capabilities fast because of governance issues and security
what are different types of platforms
what should a platform encompass - talk about it at a core level, needs to address builder and consumer in terms of solving for some key KPIs (need to lahnch capabilities fast, need a way to authenticate different users) , can have some key capabilities, we can point out examples

I think the key is that while we don't want to be too prescriptive in saying it has to be this way, we should point out some key considerations that organizations need to think about. For example, in order to scale a governance model is needed so that users of the platform don't do anything out of compliance or anything insecurely.
@ThomasVitale @krumware @Saim-Safdar would love to know your thoughts here

@joshgav +1 for the idea of the types of platforms
But the challenge is, as with Kubernetes, comes in many flavors, the platform comes in many flavors, and we need to tell what, when, why, and how to operate, for each of the types of platforms we are about to choose, which ends up in a debate for a certain type of scenario you need this plus a unification of observability platform plus data platform, we might need to have an answer ready for cross-sectional and unification, this might lead us to forget about the core problem we are addressing here, what platform actually does best, I believe we can use the cloud-native maturity model as in conjunction with defining the platform, as we can say the platform has a bear minimum of what tools people use most and ready for interoperability for day 02.
Developer platforms influence the developer experience by letting the 99% developer focus on coding without worrying about infrastructure or how to run their software. But many platforms are also designed with the flexibility to let the 1% developer explore and experiment. The developer platform, supported by architecture, DevOps and SRE teams, contains the ingredients of transformation for all of these teams and roles, fueling improvement in the developer experience, which fuels faster, safer software releases.  Words are taken from this article
What I try to understand here is who is the most consumers or end-user of the platform, is it a developer, SRE, DevOps, FinOps or we can name it, if we have an answer ready, we need to focus more on that consumer and drive the opinion of the community about other roles and we can pinpoint about the bear minimum for others consumers of the platform users. For example, here's the consumer needs platform most of the time, for this certain activity:

Creating a service that automatically deploys to the platform
Editing secrets and automatically redeploying the service
Deploying a branch to a new environment
Accessing logs
Seeing resources that a service consumes For each use case,

Hey all, just following along with interest given the why section will need to make sense with the changes y'all implement.
One thing I am seeing in this thread is a thread of conversation that seems to be moving towards defining concrete platforms that I think is taking us away from the original intention.
I want to bring back the comment from @krumware about a focus on platform as a product that will evolve with the org:

There is lots of chatter in general in the other issues and slack around examples that are "platforms as a product" and I believe this paper should be focused on helping to point out problems, approaches, and solutions experienced by people, etc, not necessarily what a platform should look/function like.

Two trends I am seeing in this conversation are:

Defining platform types The attempt to concretely list types of platforms may lead us down a path that makes readers think we are providing a blue print to success. E.g. "if I just create 4 teams for the core, deployment, data and observability platforms my organisation will be successful". I believe this was an anti pattern when we were previously discussing goals for the paper.

THE platform I think this may be a knock on from the point above, but we seem to be falling into a pattern of talking about THE platform when in our calls I hear people advocating that the platform is the same as any product: Start with something valuable, extend it to cover more uses, and of course split it into more manageable domains as necessary when you need to.

To wrap up, this is a really interesting thread, and as a (mostly) observer I just wanted to share what I am witnessing in hopes it helps converge the interesting ideas into the right set of messages for this white paper. It would be great to refer back to the intention of the paper more (and put that in writing if it isn't already) so that we can all better check that we are staying on course for this paper and allowing other interesting topics to evolve into their own offerings.

Hi @abangser
I agree with this sentiment. Ultimately every organization will have a different version of a platform that fits best to their organization. What we need to do is describe the pain points and give some guidance in terms of key things to look out for key capabilities that are worth investigating etc without getting too prescriptive
this is why imo as I had mentioned in the call a week or two ago that we should have the why section first, or relevant personas. It's hard to describe what is a platform without describing the state of platform teams, what the pain points of platform engineers and developers are and why platforms are needed. I believe putting the why first also allows us to focus more on breadth from the very beginning
@joshgav @abangser let me know your thoughts here but I do think some kind of problem statement and why we're talking about this is crucial before a what is a platform section.

Thank you all for your thoughts. I think we're all agreeing on the notion of platform types, and also agreeing that we don't want to talk about them much in this top-level doc. That is, we specifically don't want to a) canonically define any specific "types" (aka "use cases", "scenarios", "archetypes") or b) get particularly deep into how to implement any given type.
OTOH this conversation leads us to think of getting a bit more prescriptive in later work - for example we might describe a specific type in conjunction with an actual prototype of that type as worked in #293, and reference it from a doc exploring platform types.
My suggestion is we iterate on the existing 6 (2 x 3) use cases listed in the "Why Platforms" section - perhaps one app dev use case, one data science use case and one third-party COTS use case? Our goal with the examples should be to illustrate and help folks understand platforms, again not to formalize any "types" or get too prescriptive. I'll add this suggestion to #274 too.

For those interested, I have taken a stab at swapping the order of why and what sections. Please join in commenting on if this is a useful change in general, and more specifically what about the change would need to change if we were to merge it 🙇♀
https://github.com/cncf/tag-app-delivery/pull/294

Thank you all for #309, #305, #301, #294, #289 and more. The paper is much better after your contributions!


⚠ Bofrost.be has degraded performance

In 05fb6ad, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2184 ms

Resolved: Bofrost.be performance has improved in 775ef9f.


SSL-enabled Nginx Ingress Controller integrated Hashicorp Vault

Based on the nginx-alpha controller, this adds functionality to configure SSL nginx servers for ingresses requiring it, pulling in certificates from Vault.
See README.md.

Hi @devlinmr thanks for the PR. Didn't notice it till now, will take a look by monday. Feel free to tag me or @kubernetes/goog-cluster on Ingress/lb prs in the future.

Did a quick scan. This is nice! If you could add a section about "why use valut?" (just so others can make an informed decision about weather or not they want to deploy the extra rc+svc), add vault as a svc+rc, and squash the godep commits I'll take a second look.

I think travis is complaining about missing Godeps

ping @devlinmr

@devlinmr thats a crazy list of commits :) guessing it was a rebase error?

recomputing cla status...


Invalid Element.WithContext imports

Thank you very much for R10, it looks very nice. I'm trying to use the simpleView example for the new version 4 but there are compilation errors. Here is the full bug report ->
CONTEXT:
R10 version: 4.1.1 (and since version 4.0.0)
elm version: 0.19.1
DESCRIPTION:
When trying to use the examples the Element.WithContext import is missing.
REPRODUCTION STEPS:
git clone git@github.com:rakutentech/r10.git
cd r10/examples/simpleView
elm make src/Main.elm

CURRENT BEHAVIOR:
The compiler reports several errors like this:
-- MODULE NOT FOUND - ../r10/src/R10/Transition.elm

You are trying to import a `Element.WithContext` module:

6| import Element.WithContext exposing (..)
          ^^^^^^^^^^^^^^^^^^^
I checked the "dependencies" and "source-directories" listed in your elm.json,
but I cannot find it! Maybe it is a typo for one of these names?

Element.WithContext.Font
Element.WithContext.Input
Element.WithContext.Border
Element.Font

Hint: If it is not a typo, check the "dependencies" and "source-directories" of
your elm.json to make sure all the packages you need are listed there!

DESIRED BEHAVIOR:
Compile the examples without errors.

I realize the whole simpleView code just require an update to the new version with Elm UI with context ... here the pull request fixing that -> https://github.com/rakutentech/r10/pull/12
Once again, thank you for r10, it's very useful and nice !!


Add a "Do you participate in some community?" field to user profiles

Suggested by Gabriele Prestifilippo. It could allow us to link back the users to the communities they belong. And even having it as a plain text field could be fine for the time being.
Same thing maybe for Companies... but it seems more difficult to me

Good idea!
Do you use Goodreads? They have this thing called Reading Challenge. And every once in a while they look at all books you have read, but do not have a reading date in it, and ask: "have you read this book in 2016?"
We could have something similar, where we occasionally ask people: are you part of this community?

It would probably be much easier (and more effective than a plain text field) to implement something like a "+1 this community" button on the community page. I'm a little worried it could lead to competition between communities, however.


helm: Adding initContainer to Envoy Daemonset

Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[x] Are you a user of Cilium? Please add yourself to the Users doc
[x] Thanks for contributing!

Currently, it's not possible to set an initContainer in the helmchart. This is useful, for example, to load a wasm binary into a volume and then mount that volume to the envoy container.
adding initContainer to Envoy Daemonset

Seems like there is a bunch of CI failures, can you help to try the hint on how to rectify the issues? Thanks

@chifu1234 Ping, this is good to go if you address the feedback


Debug mode overwrites PYTHONPATH environmental variable

Environment data

VS Code version: 1.27.1
Extension version (available under the Extensions sidebar): 2018.8.0
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): Anaconda Python 3.6.6
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: -

Actual behavior
When running the debug mode, it runs this line in the terminal:
cd 'C:\Users\shz620\Box Sync\John\Chromatin2\Code\celllines'; ${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1'; ${env:PYTHONPATH}='c:\Users\shz620\.vscode\extensions\ms-python.python-2018.8.0\pythonFiles\experimental\ptvsd'; & 'python' '-m' 'ptvsd' '--host' 'localhost' '--port' '54685' 'c:\Users\shz620\Box Sync\John\Chromatin2\Code\celllines\overlap3.py'

and overwrites the PYTHONPATH variable. I know we can set the environmental variables in the configuration file, but it would be more convenient if the debug mode adds that path to the existing variable instead of replacing it completely.

Duplicate of #2509


⚠ Bofrost.lu has degraded performance

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

HTTP code: 200
Response time: 917 ms

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


Support changed treesitter highlight groups neovim 0.10

Neovim 0.10 changes treesitter highlight groups, which breaks highlighting a lot of ways.
https://neovim.io/doc/user/news-0.10.html#_-breaking-changes
https://github.com/nvim-treesitter/nvim-treesitter/commit/1ae9b0e4558fe7868f8cda2db65239cfb14836d0
https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups

This is already supported here https://github.com/mcchrish/zenbones.nvim/blob/453ec69d82d644ee6998a3464da49d0261df9f80/lua/zenbones/specs/dark.lua#L193-L312, correct?

Hmm, not sure. I accidentally upgraded neovim on my personal machine yesterday and just noticed that some of the highlights look pretty broken:

I haven't dug more into it, so it might only be one highlight group that needs some adjustments.

Hmm, those looks like the colors from the new default neovim colorscheme. At least for the strings.
Seems like if you remove the vim.g.zenbones_compat = 1 it works.

Thanks for the workaround, it does indeed fix the issue. Reason I ran in compat mode was to avoid having to install the additional dependency, since I don't really care about customizing the theme.

I don't think this is entirely fixed; I can reproduce with a string in a Python file:

Looks like zenbones doesn't override the default String highlight:
https://github.com/mcchrish/zenbones.nvim/blob/453ec69d82d644ee6998a3464da49d0261df9f80/lua/zenbones/specs/dark.lua#L118


Consider using #pragma once

This is a small convenience issue. Every now and then it happens that you want to create a new header file but start off by copying an existing header. Then you forget to update the include guards and spend far too long wondering why your definitions in the new header file aren't actually being defined. #pragma once would avoid this problem.
It's not standard but practically supported on every platform that we try to support. Is anyone wildly against this? Would this make someone's life a lot better? Don't care?

@msimberg the only comment I'd have is that I would like to have this used either consistently across the whole library or not at all. Otherwise I am mostly impartial on how we make sure that #includes are protected from multiple inclusion. Not sure if it is worth the effort to redo every header we have...

Weakly against.


Removing retired security hub controls

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
AWS Security Hub retired controls Lambda.4 and PCI.EC2.3. Removing them from the sample configs. See https://docs.aws.amazon.com/securityhub/latest/userguide/doc-history.html

Resolves logged issue #1192


Type of BinaryExpr is not correctly resolved in certain situations

Consider the following expression:
String s = false + "str";
Trying to resolve the type of the subexpression false + "str" gives me the following ResolvedType: PrimitiveTypeUsage{name='boolean'}.
That's wrong of course, it should be a string. When the literals are the other way around, i.e., when I try to resolve "str" + false in the following expression:
String s = "str" + false;
...it works fine, I get a ReferenceType{java.lang.String, typeParametersMap=TypeParametersMap{nameToValue={}}}. That's what I would have expected in the first case too.
Is this a bug?
I tried to resolve the expression as follows. I used JavaParserFacade.get(typeSolver).getType(node). Here, typeSolver is a CombinedTypeSolver of a ReflectionTypeSolver and a JavaParserTypeSolver of a directory with a file that contains this above expression. And of course, node is the Expression that corresponds to the sub-expression false + "str" (like, expressionStmt.getExpression().asVariableDeclarationExpr()				                .getVariable(0).getInitializer().get()).

I think @ftomassetti recently made a fix for this. Can I close this?

Well, I have solved it for the PLUS operator, but this remain open for other operations. I will create a new task on JP

Moved to JP, closing


Display caller video on ringing state

Is it possible to display caller video on ringing state to callee without answer call.

Hi @manishthakor,
You can negotiate early media using 183/PRACK, which should make this doable. You need to set rel100 to SUPPORTED or REQUIRED: https://sipjs.com/api/0.9.0/ua_configuration_parameters/#rel100
See also our documentation for progress:
https://sipjs.com/api/0.9.0/session/#progressoptions
Generally speaking we like to keep this space for bugs and feature requests. I'm going to close this issue, as it is a question, but please feel free to continue the conversation in our google group:
https://groups.google.com/forum/#!forum/sip_js
Thanks,
James


Using Docker

I hope that this is the place for Verdaccio queries. I'm having trouble working out what the convention is when using Docker. The verdaccio/verdaccio image works fine but I'm unable to use apk inside it (I get message ERROR: Unable to lock database: Permission denied etc) in order to install eg nano in order to edit the auto-created config.yaml, and if I copy in my own config.yaml (using the Dockerfile) then that file is overwritten when the container and verdaccio start up. So given those troubles I've tried to create my own Dockerfile and build up a working image. The Dockerfile I have is:
RUN yarn global add verdaccio
RUN yarn global add forever
COPY conf/. verdaccio/conf/.
CMD forever start `which verdaccio`

I'm using forever because that's what the docs suggest however the container doesn't stay up: Starting the container with docker-compose up results in:
Starting verdaccio_myverdaccio_1 ... done
Attaching to verdaccio_myverdaccio_1
myverdaccio_1  | warn:    --minUptime not set. Defaulting to: 1000ms
myverdaccio_1  | warn:    --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
myverdaccio_1  | info:    Forever processing file: /usr/local/bin/verdaccio
verdaccio_myverdaccio_1 exited with code 0

And so I don't seem to be able to get right creating my own container. So:

In general how can I use the verdaccio/verdaccio image in a live environment where I need to change the config (config.yaml)?
What am I doing wrong when trying to create my own container from my own Dockerfile?

Thanks!

Hi @robbybooker

In general how can I use the verdaccio/verdaccio image in a live environment where I need to change the config (config.yaml)?

Something like this?
http://www.verdaccio.org/docs/en/docker.html#running-verdaccio-using-docker

What am I doing wrong when trying to create my own container from my own Dockerfile?

Have you seen https://github.com/verdaccio/docker-examples already?

Thanks Juan! I've been a bit snowed under with work this week but hopefully I can get back onto this next week :D


All authenticator's names should be documented

We need to have correct authenticator names when we use file based IDPS, so we have to document all the authenticator names in the docs.
For example, when we configure linkedin authenticator we should mention the federated authenticator name as "LinkedIn" according to [1].
Likewise, we have to use the appropriate names for other authenticators as well. Therefore all the authenticator names should be documented in some place.
[1] https://github.com/wso2-extensions/identity-outbound-auth-linkedIn/blob/master/component/src/main/java/org/wso2/carbon/identity/authenticator/linkedIn/LinkedInAuthenticatorConstants.java#L27

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


[stdlib] Remove outdated miscellaneous functions

Now that we have protocol-based integers, the "miscellaneous" free functions are no longer necessary to compute leading zeros and binary logarithms. So let's remove them in favor of the corresponding modern facilities.

@swift-ci Please smoke test

Test failure is unrelated and addressed in apple/swift-lldb#300.

@swift-ci Please smoke test OS X platform


Added _t to a couple of the NVS typedefs (IDFGH-891)

Just went through and added _t to some typedefs in nvs.h to match the convention. This mainly helps with syntax highlighting, vscode recognises _t as a typedef and highlights it

 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.GOPTIONS\pfrost seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Ah ok I didn't realise the _t was originally a POSIX thing, I had just seen it used as the convention when declaring typedefs, but as @igrr says there seems to be more code in the IDF that uses _t than doesn't.

Thanks for making those changes, @Frosticles . I've cherry-picked this into our internal review & merge queue, with one small additional small change (added a backwards-compatible nvs_openmode to go with nvs_openmode_t).
This PR will be updated when it's merged.


system-containers: update maintainer for Fedora and CentOS to myself

update to reflect the current status

LGTM

LGTM


Fix duplicates in authorize search params

Purpose

This fixes duplicates in authorize search params.

Goals

Describe the solutions that this feature/fix will introduce to resolve the problems described above

Approach

Describe how you are implementing the solutions. Include an animated GIF or screenshot if the change affects the UI (email<EMAIL_ADDRESS>to review all UI text). Include a link to a Markdown file or Google doc if the feature write-up is too long to paste here.

User stories

Summary of user stories addressed by this change>

Release note

Brief description of the new feature or bug fix as it will appear in the release notes

Documentation

Link(s) to product documentation that addresses the changes of this PR. If no doc impact, enter “N/A” plus brief explanation of why there’s no doc impact

Training

Link to the PR for changes to the training content in https://github.com/wso2/WSO2-Training, if applicable

Certification

Type “Sent” when you have provided new/updated certification questions, plus four answers for each question (correct answer highlighted in bold), based on this change. Certification questions/answers should be sent to<EMAIL_ADDRESS>and NOT pasted in this PR. If there is no impact on certification exams, type “N/A” and explain why.

Marketing

Link to drafts of marketing content that will describe and promote this feature, including product page changes, technical articles, blog posts, videos, etc., if applicable

Automation tests

Unit tests

Code coverage information

Integration tests

Details about the test cases and coverage

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes/no
Ran FindSecurityBugs plugin and verified report? yes/no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes/no

Samples

Provide high-level details about the samples related to this feature

Related PRs

List any other related PRs

Migrations (if applicable)

Describe migration steps and platforms on which migration has been tested

Test environment

List all JDK versions, operating systems, databases, and browser/versions on which this feature/fix was tested

Learning

Describe the research phase and any blog posts, patterns, libraries, or add-ons you used to solve the problem.

The Auth Params are transformed in to Snake Case with this PR and that proved to be an unwanted change.
Hence, the transform logic was reverted in https://github.com/asgardeo/asgardeo-auth-js-core/pull/249.

Related Issue: https://github.com/asgardeo/asgardeo-auth-react-sdk/issues/208


Spike: Add some test cases for model evolutions

This ticket should provide some unit tests to cover the interoperability for old clients that keep pushing evolved services using legacy schemas. Some of the scenarios we want to cover:

Add new non-optional field
Add new optional field
Add item to a coproduct
Remove item to a coproduct
Change type of an existing field
Rename field.
Remove non-optional field
Remove optional field

For each of those cases, we have to consider what happens when the change affects the Request and when it affects the Response of the method.

True. I'm focused on the evolution of the requests at the moment.

Another dimension to consider is what happens when the client uses, or does not use, what has been  added, modified, or removed. Be that a field from a case class, or a case class from the coproduct.

Please, @rafaparadela could you use the https://github.com/frees-io/freestyle-rpc/tree/release/0.14.0 branch? It'd be really appreciated. Thanks.

Conclusions:
Cases:

A: Add new non-optional field in the request
B: Add new optional field in the request
C: Add item to a coproduct in the request
D: Remove item to a coproduct in the request
E: Change type of an existing field in the request
F: Rename field in the request
G: Remove field in the request
H: Add new non-optional field in the response
I: Add new optional field in the response
J: Add item to a coproduct in the response
K: Remove item to a coproduct in the response
L: Change type of an existing field in the response
M: Rename field in the response
N: Remove field in the response

A: Add new non-optional field in the request
Request: Provide default value to the new field.
case class Request(a: String, b: Int)
case class NewRequest(a: String, b: Int, c: Boolean = true)

B: Add new optional field in the request
Request: This is just another case of the previous scenario. The solutions could be to provide a default value, that presumably could be None/null.
C: Add item to a coproduct in the request
Request: No action required
case class Request(a: Int :+: String :+: CNil)
case class NewRequest(a: Int :+: String :+: Boolean :+: CNil)

D: Remove item to a coproduct in the request
Request: The only way to deal with this situation is considering this as a change of type, see next case.
case class Request(a: Int :+: String :+: CNil)
case class NewRequest(b: String :+: CNil = Coproduct[String :+: CNil](""))

E: Change type of an existing field in the request
Request: It's is impossible to deal with a type swapping if we maintain the same name of the field. So the solution is considering this replacement as a combination of removing the old field/type, and adding a new field with the new type with a default value.
case class Request(a: String, b: Int)
case class NewRequest(a: String, c: Boolean = true)

F: Rename field in the request
Request: Renaming a field is a particular case of creating a field with the new name and default value, and remove the old one, that will be ignored if old clients pass it.
case class Request(a: String, b: Int)
case class NewRequest(a: String, c: Int = 0)

G: Remove field in the request
Request: No action required. But note that the value will be ignored when old clients include it in the request.
case class Request(a: String, b: Int)
case class NewRequest(a: String)

H: Add new non-optional field in the response
Response: No action required. Old clients will ignore the value of the new field.
case class Response(a: String, b: Int)
case class NewResponse(a: String, b: Int, c: Boolean)

I: Add new optional field in the response
Response: This is a just a particular case of the previous scenario.
J: Add item to a coproduct in the response
Response: Obviously, it fails when the value is the new item. So the solution is providing a default value to the old coproduct and creating a new field with the new coproduct.
case class Response(a: Int :+: String :+: CNil)
case class NewResponse(
      a: Int :+: String :+: CNil = Coproduct[Int :+: String :+: CNil](0),
      b: Int :+: String :+: Boolean :+: CNil)

K: Remove item to a coproduct in the response
Response: No action required.
case class Response(a: Int :+: String :+: CNil)
case class NewResponse(a: Int :+: CNil)

L: Change type of an existing field in the response
Response: It requires to provide a default value to the previous type, and to create a new field with the new type.
case class Response(a: String, b: Int)
case class NewResponse(a: String, b: Int = 123, c: Boolean)

M: Rename field in the response
Response: It requires to remain the previous name/type with a default value and to add a new field with the same type.
case class Response(a: String, b: Int)
case class NewResponse(a: String, b: Int = 123, c: Int)

N: Remove field in the response
Response: This evolution should never happen. Only under the special case that the old response has a default value for the field we want to drop, then this operation is feasible, just removing the field in the new version of the response.
case class Response(a: String, b: Int = 123)
case class NewResponse(a: String)


proposal: remove the ignore-pattern flag for eslint

I noticed the --ignore-pattern flag being set to ignore all files under internals/script.
This made me wonder: why has this path been excluded in the past, does anyone know that?
I found out that this PR changed it: https://github.com/react-boilerplate/react-boilerplate/pull/417.
I would like to suggest to remove this flag from the package.json lint:eslint script. This way all code gets proper lint information and improve quality overall, especially of these scripts. This does imply that there needs to be some fixes on the code in there at the moment, but that shouldn't be that dramatic I hope.
As also per contribution guidelines I wanted to get input on this before submitting anything ;-)

Hey @joggienl, thanks. internals are excluded because they're just code for making this boilerplate run and have no effect on linting your actual project code. it'd be unnecessary to lint them every single time because the intention is that they should never change, and only be used to have the boilerplate run seamlessly.

Hey @gretzky, thanks for your response!
I noticed I do feel somewhat strong against your argument. I will try to give some thoughts I have.
So, I do think it adds value. For starters, the overall quality of the boilerplate improves. When you run eslint now on the internals folders, you get all kinds of errors and warnings. Just as the whole project, as user I would expect the same quality of code there as elsewhere. At this point it feels like these files are not being linted and that is bad. But, again, that is how it feels.
If you would never change anything in the internals folder, it could make sense to lint them every time. So I can agree somewhat here. As a side note, its not that much code so it would not hurt in terms of performance.
If you clone/fork the project you could have at least two reasons for that: either you are going to start on a new cool project and want to use this fancy awesome boilerplate, or, you want to contribute on this awesome boilerplate. For this last option the argument of "it is internal" does not count. Then it should get linted.
Also, from personal experience, I do change things in my externals folder! That's the beauty of this project. It does a lot of cool things under the hood, but can be easily changed to meet your (new) requirements.
So, what if everything would be linted by default? It might be possible to change this behaviour as soon as you run the setup or clean script (that probably means you are going to create something with the boilerplate). And by that I mean that the ignore path can be put to the script at that moment. Or maybe use the more common .eslintignore file for that. But even then I would like that to be optionally asked to me as user.
Curious!
I have some more thoughts on the eslint part of this project. But I wanted to discuss this one first :-).

Oh, I was also wondering, is there a particular reason why the issue immediately gets closed after response?

@joggienl, I closed this issue right after commenting because my comment is a direct reflection on the choices made for this boilerplate.
There is no reason to run eslint on the internals folder unless you're developing directly for the boilerplate. None of that code should be affecting your projects code at all, therefore there is no need to lint it. The boilerplate code in internals is written specifically for the boilerplate. If you find it needs linting, then I suggest opening a PR with the linted code.
If you find you're linting the internals folder often, you can easily add the folder to the eslint/ script in package.json. Otherwise, again, this boilerplate is just that- a bp, and the bp specific code shouldn't need to be linted unless you're working on this bp. It doesn't make much sense otherwise. If you still feel strongly, you can open a new RFC issue to get others perspectives.


Python Django Can Not be Recognised

I noticed that when atom recognises my python file as Python Django, linter-flake8 will just stop working. As long as I manually change it back to Python, it'll start working again. Could you please fix this issue by generalising the file type or at least let user set the dictionary themselves. Thanks.

"Python (Django)" should already be supported (part 1, part 2).
What language package are you using that is forcing Atom to recognize the file as Django instead of regular Python?

Hi @Arcanemagus
Hmm.. That's weird.
The only django package I'm using is atom-language-django (not many out there anyway.) Here are the screenshot:

And I noticed that all the python related file type I got have duplicates... Now I'm really confused...

Hi @Arcanemagus
Never mind, after I clear the cache, disable and re-enable the language-django package. Everything seems to work now and duplicates are also gone. Could be just those weird cache issue...

Sorry duplicates are gone, but the issue remains... I jumped to the conclusion there.

Hi @Arcanemagus
Sorry for all the spamming. It works on all new files after I cleared the cache. It's just won't work on that file that's already opened. Weird cache issues. Thanks for being patient.

Glad you got it worked out!


chore(deps): dependency updates

Updates of our npm dependencies that passed CI.

For this one we definitely don't want to merge in any major webpack breaking changes, so I might remove those...

📬Published Alpha Packages:@codecademy/gamut-icons@3.11.1-alpha.9b6659.0@codecademy/gamut-labs@5.4.2-alpha.9b6659.0@codecademy/gamut-styles@7.4.5-alpha.9b6659.0@codecademy/gamut-system@0.1.4-alpha.9b6659.0@codecademy/gamut@17.3.10-alpha.9b6659.0@codecademy/markdown-overrides@0.3.13-alpha.9b6659.0@codecademy/styleguide@18.5.10-alpha.9b6659.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fb5c24790032e13c6a41187--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@3.11.1-alpha.2fc297.0@codecademy/gamut-labs@5.4.2-alpha.2fc297.0@codecademy/gamut-styles@7.4.5-alpha.2fc297.0@codecademy/gamut-system@0.1.4-alpha.2fc297.0@codecademy/gamut@17.3.10-alpha.2fc297.0@codecademy/markdown-overrides@0.3.13-alpha.2fc297.0@codecademy/styleguide@18.5.10-alpha.2fc297.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fbba0223917fda25d11a518--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@3.11.1-alpha.5547cd.0@codecademy/gamut-labs@5.4.2-alpha.5547cd.0@codecademy/gamut-styles@7.4.5-alpha.5547cd.0@codecademy/gamut-system@0.1.4-alpha.5547cd.0@codecademy/gamut@17.3.10-alpha.5547cd.0@codecademy/markdown-overrides@0.3.13-alpha.5547cd.0@codecademy/styleguide@18.5.10-alpha.5547cd.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fbba16eec1893a28a2da9d7--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@3.11.1-alpha.27f88a.0@codecademy/gamut-labs@5.4.2-alpha.27f88a.0@codecademy/gamut-styles@7.4.5-alpha.27f88a.0@codecademy/gamut-system@0.1.4-alpha.27f88a.0@codecademy/gamut@17.3.10-alpha.27f88a.0@codecademy/markdown-overrides@0.3.13-alpha.27f88a.0@codecademy/styleguide@18.5.10-alpha.27f88a.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fd27729881c8941dfa7f912--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@4.3.1-alpha.afe04f.0@codecademy/gamut-illustrations@0.9.2-alpha.afe04f.0@codecademy/gamut-kit@0.2.25-alpha.afe04f.0@codecademy/gamut-labs@13.0.1-alpha.afe04f.0@codecademy/gamut-styles@9.0.1-alpha.afe04f.0@codecademy/gamut-system@0.5.2-alpha.afe04f.0@codecademy/gamut-tests@2.2.4-alpha.afe04f.0@codecademy/gamut@28.0.1-alpha.afe04f.0@codecademy/markdown-overrides@0.5.11-alpha.afe04f.0@codecademy/styleguide@32.0.2-alpha.afe04f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://6054b576f0eb57385046a1a5--gamut-preview.netlify.appDeploy Logs


fix: incorrect ordering

In lua multiline string doesn't have access by keys. And every accessing is nil, so every result is zero. That is incorrect.
I changed it to table, which contains keys as template key and values is increasing numbers.
Also added capitalizing for keys.

Thank you!
I don't have access to a computer right now to check this myself; do you mean that order[right] and order[left] would always be nil without your fix?
    table.sort(s, function (left, right)
         return (order[left] or 0) < (order[right] or 0)

Thank you again!
Oh yes right, I see that the current version is stupid; I think I forgot to split the string into a table before working with it.
Manually fixing the order.lua file is not the way to go here though. That file is generated by refresh_templates.sh, and would be overwritten in the future. What needs to happen is either an adjustment to the bash script, or preferrably some lua code that splits the string by its linebreaks (\n) and removes the empty lines.

Yes, that is!
I found it when I tried to make gitignore with Java, Gradle list and
without my fix order always is "Gradle, Java". And because of this my
gradle-wrapper.jar is not recognized :(
вс, 27 авг. 2023 г. в 17:16, wintermute @.***>:

Thank you!
I don't have access to a computer right now to check this myself; do you
mean that order[right] and order[left] would always be nil without your
fix?
table.sort(s, function (left, right)
     return (order[left] or 0) < (order[right] or 0)

—
Reply to this email directly, view it on GitHub
https://github.com/wintermute-cell/gitignore.nvim/pull/7#issuecomment-1694679957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASD3UWCZ4G3Z5XGTOFWAVZTXXNJCNANCNFSM6AAAAAA4AKI7OU
.
You are receiving this because you authored the thread.Message ID:
@.***>

I changed the bash script. It make right order.lua file as table.
All is described in commit.

I have a solution for logic capitalizing for subwords like "AndroidStudio".
Motivation: I don't like the :lower() method, because performance will be down. Even if it runs once.
My solution based on associative array in bash. Firstly script loops all files except "order"and each base name (without extensions) will maps to array by rule: {lower_case_basename}={normal_case_basename}.
And after looping I check existence of file order. If exists, I will loop lines from this file and change lowercase words to capitalized case by the associative array.
For me it look very good. But, I want to ask you about versioning. As far I know, MacOS have default bash vesrion 3.X, which doesn't contains associative arrays. I don't know what about linux, maybe some distributives have older bash version.


React not rendering after add another entry point

Hi,
Thank you for your awesome work.
I'm using this module to customize my react build. When I tried to add another entry point to the config, the React page won't render. Even the code in src/index.js file seemed not triggered to run too (I tested by putting some alert or console.log inside but when the page is opened nothing takes effect)
Has anyone faced this issue before and is there any workarounds to make this work?

how did you add another entrypoint? that doesn't seem to be in the customize-cra API...

running into the same issue. I need 2 entry points for my app and after adding the second one the app does not render anymore.
const addEntryPoint = () => config => {
 // did some changes here
 return config
}

module.exports = override(addEntryPoint())

Any updated on this?


[RFC] Aggregate total gas cost for checkpoint

This PR adds the step to aggregate all gas cost of all transactions in the latest checkpoint. This happens only after we have processed all transactions in it. We will then store it in the locals, and latter when we create a proposal, we will put it there as well.
Not sure if this is the right way to do it?
Once thing that's not very clear to me is whether this needs to go to the checkpoint locals?

hey @lxfind as per issue #2473 I want to modify the checkpoint signing and aggregation logic to take place only AFTER all transactions in the a checkpoint have been processed. This will allow us to (1) compute the gas for this checkpoint and include it, instead of waiting for the next one (2) provide a canonical causal order for the transactions (3) check that all effects are correct.
The blocker right now is that the validator needs an active component to drive the execution of transactions. I am planning to make one, or someone else can take the lead. After that we can refactor the logic in the PR to inlcude the gas cost in the checkpoint itself (rather than the next one).

Good to know! Thanks!
The utility function is probably still going to be there as it is, just the callsite will change.
Let me remove the callsite for now and add it after the refactor.


Strange behavior when locations endpoint is asked for fields across several groups

I noticed that the locations endpoint has some strange behavior when you ask it for fields from multiple "groups" (i.e., the groups in the fields list https://www.patentsview.org/api/location.html#field_list). The example below provides a minimal example where I try to get four fields that exist across four groups. I can get them one by one (iterating over the four fields), but when I ask for them all at once I don't get any results.
# Note, you need to install the development version of patentsview for this
# example to work. Install instructions are at https://github.com/ropensci/patentsview#installation.
library(patentsview)

# Four fields across four different groups
fields <- c(
  "app_country", "appcit_app_number", "assignee_first_name", "cpc_category"
)

# I get data back when I just request one field at a time
lapply(
  fields, function(x) {
    out <- search_pv(
      query = "{\"patent_number\":\"5116621\"}",
      endpoint = "locations", fields = x
    )
    out$data$locations
  }
)
#> [[1]]
#>    applications
#> 1 US, 07/633146
#> 2 US, 07/633146
#> 3 US, 07/633146
#> 4 US, 07/633146
#>
#> [[2]]
#>   application_citations
#> 1                    NA
#> 2                    NA
#> 3                    NA
#> 4                    NA
#>
#> [[3]]
#>                                                                                assignees
#> 1                                                                                NA, NA, 355732, 266721
#> 2                                                                                NA, 418770
#> 3                                                                                NA, NA, NA, NA, NA, NA, NA, Mitsuharu, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, Michihiro, NA, NA, NA, NA, NA, 382287, 400473, 424537, 424521, 223745, 31540, 228806, 449617, 89956, 154906, 312721, 224607, 362422, 26496, 319914, 388631, 151555, 91808, 435483, 336374, 393982, 395807, 14773, 268676
#> 4 Nobuo, NA, NA, NA, Katsuya, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, 438500, 208580, 107932, 254267, 455621, 75677, 230390, 28244, 259040, 134943, 359304, 425372, 251726, 72364, 50779, 320071, 300279, 66679, 329152, 164075, 126024, 33651, 177375, 386925, 405566, 25355, 94566, 158880, 45188, 88534, 200166, 47321, 239233, 103790
#>
#> [[4]]
#>          cpcs
#> 1 inventional
#> 2 inventional
#> 3 inventional
#> 4 inventional

# ...But not when I ask for them all at once
search_pv(
  query = "{\"patent_number\":\"5116621\"}",
  endpoint = "locations", fields = fields
)
#> $data
#> #### A list with a single data frame on a location level:
#>
#> List of 1
#>  $ locations:List of 4
#>   ..$ : list()
#>   ..$ : list()
#>   ..$ : list()
#>   ..$ : list()
#>
#> $query_results
#> #### Distinct entity counts across all downloadable pages of output:
#>
#> total_location_count = 4

Created on 2019-11-25 by the reprex package (v0.3.0)

Hi crew102,
Thank you for bringing this issue to us. The problem you are having seems to stem from the PatentsView package in r rather than the API itself.
To run this query using the API you can use the following query language:
https://www.patentsview.org/api/locations/query?q={"patent_number":"5116621"}&f=["app_country","appcit_app_number","assignee_first_name","cpc_category"]
This will display the results you were looking for without needing to run each field individually.
Please let us know if you have any future issues with the API.

So it looks like it has something to do with the matched_subentities_only parameter.
When I set matched_subentities_only to false, I get results:
https://www.patentsview.org/api/locations/query?q={"patent_number":"5116621"}&f=["app_country","appcit_app_number","assignee_first_name","cpc_category"]&o={"include_subentity_total_counts":false,"matched_subentities_only":false,"page":1,"per_page":25}&s=
However, when I set matched_subentities_only to true, I don't:
https://www.patentsview.org/api/locations/query?q={"patent_number":"5116621"}&f=["app_country","appcit_app_number","assignee_first_name","cpc_category"]&o={"include_subentity_total_counts":false,"matched_subentities_only":true,"page":1,"per_page":25}&s=
I'm not 100% clear on what this parameter does, but I know that the results of the query shown above used to return results (while it's not returning results now). Am I missing something, or has something changed with the API? Thanks.

Thank you for bringing this to our attention. It looks as though there is an issue with the matched_subentities_only parameter at the moment. We are working to fix this and will update you and close this issue once it has been resolved.


feature request: expose template info in the custom action

i'm writing a custom action by following https://backstage.io/docs/features/software-templates/writing-custom-actions
in the custom action handler, the ctx object provides the baseUrl of the template, but i want to know the template name as well
Feature Suggestion
import { createTemplateAction } from '@backstage/plugin-scaffolder-backend';
import fs from 'fs-extra';

export const createNewFileAction = () => {
  return createTemplateAction<{ contents: string; filename: string }>({
    id: 'mycompany:create-file',
    schema: {
      input: {
        ...
      },
    },
    async handler(ctx) {
      // THIS IS WHAT I NEED, TO GET THE TEMPLATE NAME OR MORE TEMPLATE METADATA
      ctx.logger.info(ctx.template.name)
    },
  });
};

Possible Implementation

Context
we already have a scaffolding service similar to the backstage scaffolder, i'm not trying to integrate the existing one into backstage, i'm building the adapter custom action, Ex. use the backstage UI take the params, and call the custom action which call our existing scaffolding service rest api to create the project, the existing scaffolding service take template name as param.

Is this something you'd want to contribute @missedone? :pray:

I'm looking for good first issues to tackle - I can look into this if there's still a need for it.


issues with other plugins such as telerik ui

Can you shine some like on me as to how i would be able to use a ui component with this package?
Let me know,
Thanks.

Sorry for the late reply.
I am trying to figure that out too. Will keep you posted. 👌

This project is now deprecated... sorry.


MDI-319

Looks good, just spotted one place where we can reduce code duplication. See comment on the specific commit.

Merged. @alexandertakacs


Implement raw frame cleanup

Make the default behaviour that the Exposure() class empties raw frames after CDS is performed, to save on memory (and include a parameter to turn this behaviour on and off e.g. cleanup=True/False)

On initialisation, Exposure() takes the optional parameter cleanup (defaults to True). If cleanup is True, function cleanup_frames() is called, which empties out the raw_frames attribute.


Clarify what a breaking change is

This comment had me thinking that we should clarify within what should count as a breaking change in the context of our modules.
For example:

Upgrading the module requires a change to the module call (i.e., new required variable, change to variable type, moving resources in state required...)
Upgrading the module requires a change outside of Terraform (i.e., key authentication disabled by default, so unless module call is updated to explicitly enable key authentication, applications will have to be updated to use Entra authentication instead)

Perhaps a better idea would be to add a section to CONTRIBUTING.md clarifying how to perform a good review of a PR? Including how to determine what's a breaking change.


Expand editor support with integrated code-server

This issue keeps track of the integration of the code-server browser based VS Code editor.
As per @howie6879's recommendation we'll look into how and whether it makes sense to expand the available editors beyond JupyterLab.
At the moment VS Code can be used with Orchest by opening the orchest/userdir/ directory in VS Code directly on the host on which Orchest is installed (or through SSH if it's on a remote server).

With the upcoming services feature, users are able to use the VC Code editor (through code-server) from within Orchest.


CSRF token validation failed

I only did a
#php ./artisan config:clear
#php ./artisan config:cache
and I'm unable to log in anymore, what did I break?

Symfony\Component\HttpKernel\Exception\BadRequestHttpException thrown with message "CSRF token validation failed."
Stacktrace:
5 Symfony\Component\HttpKernel\Exception\BadRequestHttpException in /var/www/Cachet/vendor/graham-campbell/exceptions/src/Transformers/CsrfTransformer.php:36
4 GrahamCampbell\Exceptions\Transformers\CsrfTransformer:transform in /var/www/Cachet/vendor/graham-campbell/exceptions/src/ExceptionHandler.php:132
3 GrahamCampbell\Exceptions\ExceptionHandler:getTransformed in /var/www/Cachet/vendor/graham-campbell/exceptions/src/ExceptionHandler.php:112
2 GrahamCampbell\Exceptions\ExceptionHandler:render in /var/www/Cachet/bootstrap/cache/compiled.php:2106
1 Illuminate\Foundation\Http\Kernel:renderException in /var/www/Cachet/bootstrap/cache/compiled.php:2022
#0 Illuminate\Foundation\Http\Kernel:handle in /var/www/Cachet/public/index.php:54

Did you refresh the login page first before trying to login?

Yep, even tried another browser....

I take it you're all setup?

Well, it was set up 2 months ago....  Wished I never touched it  now.
What does this error really mean?

Most forms have a hidden input field called _token. The server checks that the _token value matches a server-side token. If it doesn't, then validation fails.
What version are you running on?

The form has a _token, is is meant to match the .env's APP_KEY?

Nope, the APP_KEY value is there to encrypt data like sessions.
Try the following:

Run php artisan config:cache.
rm -rf bootstrap/cache/*

Anything?

Still nothing...... Is it that easy to break?
What is the best way to upgrade? Is it just like an install? eg. git clone blah

Maybe try clearing your sessions?

What is the best way to upgrade? Is it just like an install? eg. git clone blah

Did you run artisan app:update?

Are you on 2.x?

Clearing browser sessions? I've tried 3 separate browsers though. About to give up.
app:update is unknown so I'm guessing I'm on an old version?
All this because I'm trying to find out why it wont connect to Google's SMTP server (G Apps)

Clearing browser sessions?

Clear the session storage on the server side.

Still errors

php artisan cache:clear?

Ditto.

What session driver?

from .env:
CACHE_DRIVER=array
SESSION_DRIVER=array
QUEUE_DRIVER=database
Not sure!

Can you try using apc as your SESSION_DRIVER?

That worked!
What version am I using, how do I check?

You could do git log -n1 and tell us what the SHA-1 commit is?

14ec134ac1e30249a2953e973c2fdf3be22ea111

Looks like you're using 2.0-beta1.

SESSION_DRIVER=array

You deficiently don't want that! That turns sessions off essentially.

Is this in the docs, I wonder?

Why would anyone choose array?

We don't suggest that anyone uses it...

Well, I didn't actually add array to them, I assume it did it by itself, and as it worked, I just left them.
I've set both to 'apc' now.


Added game example

[x] All tests pass
[x] I have run npm run gen-doc

Description
Adding game example.
References
Issue #222

Merged in commit https://github.com/yagop/node-telegram-bot-api/commit/a3268164f580f2aa8dd5c94b456a80259a5f4611
Thanks @MCSH. :+1:


Hiding Secrets options when Actions feature is disabled

Secrets options should be hidden if Actions feature is disabled.
This fixes in release/v1.19. In main probably fixed in 63a401ac40ce2cc19c7d0341d11d434b568653fc (didn't check).
Fixes: 659055138b6d32492b20c9f4d1d5a3cdaa47188d
Author-Change-Id: IB#1134011

As far as I know, there are plans to use secrets for more than just Actions, so I'm rather against this change.

(And no, it's not "fixed" on main as it is not supposed to be "fixed")

Still, enhancements are typically not backported once x.0 is released.
So I'm still rather against this change.

there are plans to use secrets for more than just Actions

Could you elaborate?
If optional, should be equipped with option to disable it.

Nevertheless, enhancements are typically not backported once x.0 is released.

It's not enhancement but bugfix IHMO (assumes that Secrets are used only for Actions in 1.19).

At the moment, secrets are only used for Actions. However, I've already heard of plans to allow them for other things as well, i.e. to send them inside webhooks, for the package registry or for external CIs. If I remember correctly, it was @lunny who expressed something in that direction.

Just my opinions:

Admit that the secrets Gitea has now are only used for Actions, it should be disabled when Actions has been disabled.
One day secrets may be used for something else, but don't mix them.

Add a type for secrets, like actions and webhook
Different types of secrets have different UI entry points.
Actions will use secrets with actions type only.

Then the UI entry point for secrets for Actions should be disabled when Actions have been disabled, but others could be enabled.

So I agree with the idea of PR, but I also agree with delvh's opinion: it's not a bug. I don't think it has to be fixed in 1.19.

Secrets should be split into serval groups and different groups should not share the secrets. So the current secrets under actions should be the part used only by Actions.

Secrets should be split into serval groups and different groups should not share the secrets. So the current secrets under actions should be the part used only by Actions.

That does sound like confusing UI, I think there should only be one set of secrets, per repo/org and global for the whole server.

Secrets should be split into serval groups and different groups should not share the secrets. So the current secrets under actions should be the part used only by Actions.

That does sound like confusing UI, I think there should only be one set of secrets per repo/org and a global set for the whole instance, managed in the admin ui.

Since currently all secrets are for Actions, I think we can think it's all for Actions. Once we have another PR that supports to use secrets on other places, then it's the responsibility of that PR to do the UI change.

Secrets should be split into serval groups and different groups should not share the secrets. So the current secrets under actions should be the part used only by Actions.

That does sound like confusing UI, I think there should only be one set of secrets per repo/org and a global set for the whole instance, managed in the admin ui.

Since currently all secrets are for Actions, I think we can think it's all for Actions. Once we have another PR that supports to use secrets on other places, then it's the responsibility of that PR to do the UI change.

Visually, I'd follow GitHub, e.g.
Repo > Secrets > Actions (per-repo)
Org > Secrets > Actions (per-org)
Admin > Secrets > Actions (global)

Secrets should be split into serval groups and different groups should not share the secrets. So the current secrets under actions should be the part used only by Actions.

That does sound like confusing UI, I think there should only be one set of secrets per repo/org and a global set for the whole instance, managed in the admin ui.

Since currently all secrets are for Actions, I think we can think it's all for Actions. Once we have another PR that supports to use secrets on other places, then it's the responsibility of that PR to do the UI change.

Visually, I'd follow GitHub, e.g.
Repo > Secrets > Actions (per-repo) Org > Secrets > Actions (per-org) Admin > Secrets > Actions (global)
in case of name conflict, more specific secrets win, e.g. repo > org > global.

I think it's OK. Let's close this one.
@pboguslawski what do you think about this?

@pboguslawski what do you think about this?

You decided that secrets should be part of Actions in 1.19 if understood correctly but now are not (Secrets visible even if actions are disabled). This may confuse users.

Current Secrets are only for Actions, in the future, we can have more options, like what Github did.

So I can accept both changes for now.

[ ] Solution 1: Since no more other type secrets currently, move secrets under Actions and hide all of them when actions disabled.
[ ] Solution 2: Move secrets out of Actions as a standalone tab and creating a sub type named Actions like what Github did.

Proposed changes are enhancements (problably interfering with 63a401ac40ce2cc19c7d0341d11d434b568653fc) and this PR is quick bugfix for 1.19 only. Feel free to close it if you don't like fixing it in 1.19.


[INLONG-674] adjust HiveSinkInfo in inlong-manager

Codecov Report

Merging #517 (e3f6f99) into master (21939f6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master    #517   +/-   ##
========================================
  Coverage      7.73%   7.73%
  Complexity      565     565
========================================
  Files           355     355
  Lines         31077   31077
  Branches       4970    4970
========================================
  Hits           2403    2403
  Misses        28185   28185
  Partials        489     489

Continue to review full report at Codecov.

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


Bad state: No element related to text line selection

Is there an existing issue for this?

[X] I have searched the existing issues

Flutter Quill version
10.7.5
Steps to reproduce
dont know
Expected results
no exception
Actual results
#0 _Array.first (dart:core-patch/array.dart:52)
#1 RenderEditableTextLine._getEndpointForSelection (package:flutter_quill/src/editor/widgets/text/text_line.dart:928)
#2 RenderEditableTextLine.getBaseEndpointForSelection (package:flutter_quill/src/editor/widgets/text/text_line.dart:909)
#3 RenderEditor.getEndpointsForSelection (package:flutter_quill/src/editor/editor.dart:901)
#4 RenderEditor.getOffsetToRevealCursor (package:flutter_quill/src/editor/editor.dart:1288)
#5 QuillRawEditorState._showCaretOnScreen. (package:flutter_quill/src/editor/raw_editor/raw_editor_state.dart:1169)
#6 SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1397)
#7 SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1331)
#8 SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:1176)
#9 _rootRun (dart:async/zone.dart:1399)
#10 _CustomZone.run (dart:async/zone.dart:1301)
#11 _CustomZone.runGuarded (dart:async/zone.dart:1209)
#12 _invoke (dart:ui/hooks.dart:314)
#13 PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:419)
#14 _drawFrame (dart:ui/hooks.dart:283)
Additional Context

Screenshots / Video demonstration
[Upload media here]

Logs
[Paste your logs here]

Can you tell us the steps you took to create this problem?

@tschiekdev Can you tell us the steps you took to create this problem? If you can provide a video, could be useful.

No, unfortunately not. The users use my app and the error handler catches the errors.
It would be desirable if the quill editor would not produce so many errors and would work more stable and reliable.

It would be desirable if the quill editor would not produce so many errors and would work more stable and reliable.

That's what we're working on, we will need more details to start providing the fix.

Which version are you using? I know 10.7.5, but if i check the line 928 of text_line i expected found a assertion, but i found just a method. Probably we need more detail to reproduce this error.


Add vLLM on Ray microservice

Description
Add vLLM on Ray microservice
Issues
n/a.
Type of change

[ ] New feature (non-breaking change which adds new functionality)

Dependencies
Tests

Please add the e2e test like this one, https://github.com/opea-project/GenAIComps/blob/main/tests/test_llm_summarization_tgi.sh


Add option to toggle frustum culling in replay renderer.

Motivation and Context
This changeset adds a config option to disable culling for replay renderers.
The classic replay renderer currently has an issue related to frustum culling. This allows to work-around the issue for immediate needs.
How Has This Been Tested
Tested locally in Python viewer.
Types of changes

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

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

LGTM but Mikael and John should reach consensus before merging.

If this works how it is needed, then I'm fine with it. It just seems kind of confusing to me.
If the purpose of this new flag to enable frustum culling in replay regardless of simConfig setting then I think the naming and structure is fine
If the purpose of the new flag is to disable culling in replay regardless of simConfig setting then I would rename it.
If the purpose is to provide independent Replay control of culling, then the name is also fine but then SimConfig's setting should be ignored.

After discussing with Mikael, I see that SimConfig's role in this process with ReplayRenderer is not as relevant as I had initially thought (not relevant at all, in fact :) ), so many of my suggestions are equally irrelevant :)


Allow empty tuple() call with C408 (unnecessary-collection-call)

It's totally valid but () is a bit of a strange syntax to actually spawn an empty tuple, especially when it's used within another call. e.g.
action = core.ClassName(core.ActCon.STUB, tuple())  # noqa: C408
action = core.ClassName(core.ActCon.STUB, ())

my_list.append(tuple(1, 2, 3))  # perfectly valid C408 warning
my_list.append((1, 2, 3))
my_list.append(tuple())  # noqa: C408
my_list.append(())

I suggest adding a setting to allow empty tuples, but possibly just allowing it generally.
Ruff version: 0.7.0

Hi @LordAro
I'm struggling to understand how your question relates to C409 because the rule doesn't trigger for me with the given code example  (see this playground). However, your example raises C408 and the rule recommends using literal syntax over function calls.
Raising C408 for tuple is exactly the intent of the rule. That's why I don't think they should be excluded regardless of their position (see the rule documentation for the motivation). You can disable C408 when you prefer the method form.

Ah, I screwed up the numbers when constructing this example didn't I? I've updated the original issue
C408 pertains to all collection types - I'm saying that empty tuples could be a special case because the syntax (parens) is used for so much else

Although tbh maybe it's more relevant for 1-length tuples, as (foo) isn't a tuple but (foo, ) is

Thanks for updating the issue. Glad to hear that we're talking about the same :)
I agree, () is very unambiguous. I can see how (foo,) is harder to spot. But the rule isn't just about readability:

It's unnecessary to call, e.g., dict() as opposed to using an empty literal ({}). The former is slower because the name dict must be looked up in the global scope in case it has been rebound.

That's why I still think we should keep flagging all tuples, including zero and one element tuples because it applies to them as well.

I think it's reasonable for us to keep this as-is though understand and respect the motivation for thinking otherwise.


Enable mingw debugging to async-break.

Enable mingw debugging to async-break. This is used for breakpoint
setting in run mode and for async-break. Note that this does not
work for cygwin which has a number of issues blocking async-break.
For the first release, the user will have to manually ctrl-c the
debuggee on cygwin.

@gregg-miskelly @edumunoz @andrewcrawley @paulmaybee @chuckries

:shipit:

@dotnet-bot build please

:shipit:

:ship:


Update eslint config standard

Semver
This project uses semver, please check the scope of this PR:

[ ] #none#
[ ] #patch#
[ ] #minor#
[x] #major#

Examples:

NONE

README.md changes
test additions
changes to files that are not used by a consuming application (.travis.yml, .gitignore, etc)

PATCH

backwards-compatible bug fix

nothing about how to use the code has changed
nothing about the outcome of the code has changed (though it likely corrected it)

changes to demo app (/tests/dummy/)

MINOR

adding functionality in a backwards-compatible manner

nothing about how used to use the code has changed but using it in a new way will do new things
nothing about the outcome of the code has changed without having to first use it in a new way
addition of new CSS selectors
addition of new ember-hook selectors

MAJOR

incompatible API change

using the code how used to will cease working
using the code how used to will have a different outcome
any changes to CSS selector names
any removal of CSS selectors
any changes to ember-hook selectors
possibly changes to test helpers (depends on the changes made)

any changes to the dependencies entry in the package.json file

CHANGELOG

Update eslint config standard for Ember 3

👍
sweet, was looking for this the other day.  thanks.

👍


System is not defined

After webpack 4, it seems System.import is deprecated, which results in this issue

Thanks for your feedback!


README update - better dev experience

Yarn Command Reference
yarn
Installs all dependencies listed in the root package.json
Could you add this as well please.
This is currently missed.
And good to know that you have self reviewed and removed run
Originally posted by @harshith-venkatesh in https://github.com/Real-Dev-Squad/website-calendar/issues/42#issuecomment-1213311996

yarn
Installs all dependencies listed in the root package.json

Please add the above statements to the README.md file

can i take this?

https://github.com/Real-Dev-Squad/website-calendar#using-a-template , in here why is it ,npx create-remix@latest since we are using yarn??

Please remove using a template section as well as it is not relevant now
Thanks @chiranjeevkapoor for pointing it out

@harshith-venkatesh will do when I raise the PR.

can I take this task?

https://github.com/Real-Dev-Squad/website-calendar/pull/61


undefined is not an object stylesheet$flatten.height when adding icon

Now, this error is happening a lot of time now, and I am always looking for an alternative all the time.
When i import Icon from ui-kitten components, all the time it is throwing me this error.
And I just added the icon as given in the documentation.
Please have a look.
<Icon name="star" width={32} height={32} fill="#3366FF" />
Is there anything wrong in the way I do things here?

I guess this can be caused by recent updates of react-native-svg library.
Try <Icon style={{ width: 32, height: 32 }} fill='#3366FF' name='star' />


Timestamps to differentiate identical lines

Every good log needs timestamps. :) Even though Scout is working just fine, seeing that something actually happened in the midst of a hundred identical lines would increase the feeling that Scout is actually doing its thing.

This feature is currently in Scout-App 2. Closing this issue.

Scout-App 2 (2016)


CompletionSession selection

This should fix issue #1 and add support for completion.

Works fine. Thank you very much for contributing


getPublicKeysFromVerificationScript(verificationScript) returns unencoded or encoded keys

I'm working on multi signature signing and realized that depending on what kind of verification script is feeded to
getPublicKeysFromVerificationScript it returns either unencoded or encoded keys.
For a multi signature account it returns the encoded keys, for a verification script from a normal account (in my case coming from a Ledger device) it returns the decoded ones.
This results that bulidMultiSig fails as there is no match between encoded and decoded keys, see comments
  static buildMultiSig(tx, sigs, acctOrVerificationScript) {
        const verificationScript = typeof acctOrVerificationScript === "string"
            ? acctOrVerificationScript
            : acctOrVerificationScript.contract.script;
        // *** publicKeys are encoded ****
        const publicKeys = wallet_1.getPublicKeysFromVerificationScript(verificationScript);
        const orderedSigs = Array(publicKeys.length).fill("");
        sigs.forEach(element => {
            else if (element instanceof Witness) {

                // **** Keys are returned decoded ****
                const keys = wallet_1.getPublicKeysFromVerificationScript(element.verificationScript);
                if (keys.length !== 1) {
                    throw new Error("Given witness contains more than 1 public key!");
                }

                // **** Position is null as we match decoded against encoded ****
                const position = publicKeys.indexOf(keys[0]);
                orderedSigs[position] = wallet_1.getSignaturesFromInvocationScript(element.invocationScript)[0];

Can you provide an example of the verification script for your normal account? I am surprised that your verification script is using an unencoded key. The method getPublicKeysFromVerificationScript does not contain any transformation logic, it merely reads the script and extracts the correct string.

hm, maybe that's what I'm doing wrong. I modified the signWithLedger method to return the witness that I'm passing then to the buildMultiSig method.
  async signatureFromLedger(
    unsignedTx: Transaction | string,
    acct: number = 0
  ): Promise<string> {
    try {
      const data =
        typeof unsignedTx !== "string" ? unsignedTx.serialize() : unsignedTx;
      const publicKey = await this.getPublicKey(acct);
      console.log("ledger pubkey", publicKey);
      const invocationScript = `40${await this.getSignature(data, acct)}`;
      const verificationScript = wallet.getVerificationScriptFromPublicKey(
        publicKey
      );

      let keys = wallet.getPublicKeysFromVerificationScript(verificationScript);
      console.log("calculated pubkeys", keys);

      let witness = new tx.Witness({
        invocationScript: invocationScript,
        verificationScript: verificationScript
      });
      return witness;
    } finally {
      //await this.device.close();
    }
  }

There are a few naive implementations that I see that we can fix to make this tighter. What is the keylength that the ledger returns?

So I'm reusing the method getPublicKey, which in the end returns a 130 chars key.
  /**
   * Retrieves the public key of an account from the Ledger.
   * @param {number} [acct] - Account that you want to retrieve the public key from.
   * @return {string} Public Key (Unencoded)
   */
  async getPublicKey(acct: number = 0) {
    try {
      const res = await this.send("80040000", this.BIP44(acct), [
        this.VALID_STATUS
      ]);
      console.log("Res", res)
      // => Uint8Array(67)
      console.log(res.toString("hex"))
      // string.length => 134 chars
      const pubKey = res.toString("hex").substring(0, 130);
      // string.length => 130 chars
      this.publicKey = pubKey;
      console.log("Pubkey", pubKey)
      return pubKey;
    } catch (err) {
      throw this.evalTransportError(err);
    }
  }

And that is the issue. getVerificationScriptFromPublicKey is a native implementation currently and only accepts encoded public keys. Try encoding the key first.

hm, would probably be good to add that to the method documentation. I would expect it not to be encoded if it is not stating it explicitly


Minor typo in breakpoints.md description

This isn't a bug report. I found a typo in your documentation that I decided to fix.
Here is the relevant link: https://github.com/twbs/bootstrap/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
Opening a PR shortly.

Fixed by #32740.

Fixed by #32740.


any chance you could pull the MileSense fork?

This version, which represents the pypi package, has some fatal issues fixed by MileSense.  Any chance you could merge and republish?  for instance, it imports django.contrib.admin.models.User, which doesn't actually exist (its django.contrib.auth.User)
https://github.com/MileSense/django-authy-admin

Any chance this pull will be done?


Include dependency on libpng and tidyverse package

Minor additions to dependencies to resolve:
Shiny server requires libpng, but this is not in our R Studio (see here)
The Data Science team is recommending the use of Tidyverse packages as sensible defaults, so it makes sense for this to be installed by default on the platform.

Closing as these changes are already in master