Proposal to add a 'version' value into the message object to support a more granular versioning

Introduction
This proposal is to add a version field into the message object. This is to allow a more granular versioning.
Problem Statement
Currently, versioning in AsyncAPI is done at the application level. This inherently implies that all messages are of the same version, or that events do not hold a version at all. This approach works when an application fully controls its specifications/messages, with no cross references from other applications. An example are openAPI specs.
However, in environments with continuous development and/or fast iterations, application level versioning looses its benefit. Versioning becomes more important at the message level. Without granular versioning, any change in the application version applies to all messages it sends and receives, which can be problematic as shown in the example.
Example
Payment-service (v1.0.0) receives [billing-agreement-created...], sends [payment-success].
Comms-service (v1.0.0) receives [payment-success, payment-failed, billing-agreement-created, address-changed..] sends [communication-send...]
All the events received and sent are then version 1.0.0.
If the communication-send message needs a new field (e.g., adding SMS as a type), the comms-service would become v1.1.0, and all its messages would then be version 1.1.0.
This change would require updating all other AsyncAPI files for payment-service and others, as the comms-service would be otherwise consuming message versions no-one is producing.
Proposed Solution
The proposal is to add an optional version on the message object level to allow for granular versioning.
This in turn will provide more visibility into what has changed, as an application version can change without modifying any of the underlying messages it sends and/or receives.
Example outcome
With the proposed solution, we can fix the message version in the comms-service for messages that haven't changed:

Comms-service (v1.1.0) receives [payment-success (v1.0.0), payment-failed (v1.0.0), billing-agreement-created (v1.0.0), address-changed (v1.0.0)..] sends [communication-send (v1.1.0)...]

Alternatives

Using a new message for each version as exemplified in https://eventstack.tech/posts/versioning-is-easy . The downside is that you still need to increase the application version to provide the new version of the application, what in turn means all other messages increases their version.
Using message traits might be able to provide a version, but feels more of an "weak" link
Using the specification-extensions, like x-version or x-message-version, can give us also a version to use. While this might work for some extensions, would make it easy for conflicting standarisation when 2/3 ways will compete for a standard version.

NOTE: Not sure if this relates in part to https://github.com/asyncapi/spec/issues/432 . I made it a different proposal as it seems granular enough.

I'm all in with this proposal. Just want to leave a not on the following:

This inherently implies that all messages are of the same version, or that events do not hold a version at all.

I think it's more like the latter. The version of the application has nothing to do with the version of the messages. This surely can be clarified.

Sure, in my case the implementation of this in EventCatalog has assumed the events has a version, what has created the problem for me.
I agree the spec don't imply events have a version. Do you want to edit my message/proposal ? Not sure how this contributions work on that aspect, and if the proposal gets edited or not. Thanks a lot!
Also, if this gets approved, I am happy to make the changes in the parser, spec files, etc. It shouldn't be a big job (famous last words)...

I +1 this. I believe it is a good addition @IsmaelMartinez 💯

Do you want to edit my message/proposal ?
No, I think that's fine. Just wanted to clarify it 👍

Sounds like a good proposal yea 👍

Sounds like a good proposal yea 👍 Maybe make global version optional 🤔

Can that be for another RFC ? Otherwise changes can grow arms, legs and tentacles ;)

Good to see some movement in the spec proposals, thanks @IsmaelMartinez
I saw your PR and have some questions/requests - I put these here in the issue as for now the PR is very small without much detail.
There is an old and similar issue, not sure if you had a chance to see it: https://github.com/asyncapi/spec/issues/697
It is schema versioning related - but seems to be the same topic, just a different level of defining version.

If the communication-send message needs a new field (e.g., adding SMS as a type), the comms-service would become v1.1.0, and all its messages would then be version 1.1.0.

Application level version is application-related and does not imply the version change on the message level.
Have a look at the description of the issue I linked. It is not always the way you described. You may have an app that sends multiple messages, that differ a bit, and in the majority of cases, each version goes to a different channel.
With the above, we already end up with the option to have a version maybe on the message level, maybe on the schema level, but maybe also on the channel level. Have a look for example at below case study (channel names in the example AsyncAPI document) and notice how Adeo also specifies the version in the name (address in v3) of the channel.
https://www.asyncapi.com/casestudies/adeogroup
To complex things even more, you can see that it may also happen that a version of the schema, like also in the case of CloudEvents, can be defined at the schema level because integration systems require it in the payload -> https://www.asyncapi.com/casestudies/adeogroup#versioning-of-schemas
With all this EDA complexity that we have to deal with, and different patterns around - does it make sense to somehow arbitrarily say that versioning should be defined on the message level? Of course, I might be missing something and have wrong assumptions - sorry for that.
Sorry but just wanted to drop all these questions to make sure we clarify some things first.
Also for me a must-have for this proposal is to have some real examples of AsyncAPI documents with this new version flag. If you could take some time and show some of your real AsyncAPI documents and how they would benefit from this new flag - anonymize them to the maximum if needed. What is the benefit? for docs readers that they can see a kind of drop-down and switch between message definitions in different versions? but messages are usually shown in context of an operation, would you have a case where you have one operation that might receive two different message versions? like success-v1 or success-v2
This is what travelling is for, to sit at the airport for a few hours and find time to interact in GitHub issues 😄
Thanks again a lot for the proposal 🙏🏼 🙏🏼 🙏🏼 and please do not feel discouraged about all these questions 🙏🏼

Just read the other issue and it seems the consensus was going towards a similar approach (but using a metadata object, so using the data/metadata pattern). Happy going that direction, but that would probably mean moving other parts into it.

In most cases it is good practice to use the tolerant reader pattern. And assuming you are referencing to senatic version styled versions.
The minor and patch level version or only interesting for debug uses cases, because extra field can safely be ignore by the tolerant reader / receiver.
But major changes have to be rollet out in steps to not bild the life cycle of receiver and sender. Meaning eigther sender habe to send v1 and v2 or receiver have to listen on both and process what is send.
There for, for typed language based software need to get find the major version before parsing the message. This is why the major versions habe to be part of the channel / topic name or a header field (depending on used messaging solution / transport system).

In most cases it is good practice to use the tolerant reader pattern. And assuming you are referencing to senatic version styled versions.
The minor and patch level version or only interesting for debug uses cases, because extra field can safely be ignore by the tolerant reader / receiver.
But major changes have to be rollet out in steps to not bild the life cycle of receiver and sender. Meaning eigther sender habe to send v1 and v2 or receiver have to listen on both and process what is send.
There for, for typed language based software need to get find the major version before parsing the message. This is why the major versions habe to be part of the channel / topic name or a header field (depending on used messaging solution / transport system).

I think that works then well for putting the version on the message level. It is outside of the payload and a property of the message envelope. That should allow for easier locating the versions, for example if you need to parse $ref objects.
Version should not be tied to semver IMO, as I personally only find useful tracking breaking changes in EDA. It should support any version, reason why I think a string should do the job.
Let me put some some examples to see the problems and options this provides.
components:
  messages:
    Banana:
      version: '1'
      name: 'banana'
      payload:
         something: 'yeah'
         ...
   Banana_v2:
      version: '2'
      name: 'banana'
      payload:
        schemaFormat: 'application/schema+json;version=draft-07'
        "$ref": 'BananaSchema-v2.schema.json'
   UniquePlatano:
      payload:
         key: value
         ...

I can see a 'small' caveat/issue with this solution, as the message identifier needs to be different for each version (to avoid clashes). I think that is ok to leave to the user to decide.
It is then possible to have 2 messages with different version by using the combination for name and version, but both aren't required, so this is more of a tool/implementation decision.
To resume, you can have what you got now that don't include a version:
components:
  messages:
    Banana_v1_or_wathever_you_want_in_here:
    ...
    Banana_e197238b-f384-4d1f-8b90-aa403a2a384b:
    ...

you can have versions on those messages:
components:
  messages:
    Banana_v1_e197238b-f384-4d1f-8b90-aa403a2a3811:
       version: '1.0.0'
       ...

You can even add version and name, so you can know when a message representation is a versioned version of another message
components:
  messages:
    Banana_v1:
       version: '1.0.0'
       name: 'banana'
    Banana_e197238b-f384-4d1f-8b90-aa403a2a384b:
       version: '2.0.0'
       name: 'banana'
       ...

But true that only adding the version only provides you with the version of the message, but doesn't tell you much about the message itself nor the relationship with other messages.
What do you think lovely people? I am probably missing a lot of caveats and happy to learn about them! Happy to be completely wrong also, so do shout!

yeah, you have Banana at version 1 and Banana_v2 at version 2 but these can be 2 different version of totally different bananas, and of course, someone can do Banana_v2 at version 1 and then what does that even mean. This is why I'm asking what is the benefit of that flag.
Also, regarding the related issue of schema versioning - this is why in this other discussion it was proposed to have versioning on schema level. This way you see that one message has multiple schema versions, and because they are part of one message, it is clear what is the relation.
The problem with versioning in the schema level only is that then you lose access to all the other message-level flags that are useful, like for example deprecated or even examples.

I feel it goes better in the message object rather than the schema. Mainly because it would be more difficult to apply to external schemas. Like when importing JSONSchema, OpenAPI, Avro or similar.
Maybe we can use the version and name?!?. We can require both if a version is provided?!? Use the name as in the blog? I need to think about it.
I understand this is a complex issue. We all do it differently, as we are pragmatic, and have different problems. Happy to explain how we do it, if that helps. The questions I have currently are:
What do we need to support a message that has multiple versions of a schema? Is this the right question? What do you think?

What do we need to support a message that has multiple versions of a schema? Is this the right question? What do you think?

but is it the right direction? As I wrote, if we go schema-versioning-way then we lose access to all the other properties of  message object, like for example deprecated. I can imagine pretty quickly that someone wants to have multiple versions of a message, and mark one of these as deprecated. With versioning on schema level - not possible.
message level versioning is better, but again, what is the value if you still cannot set a relation between messages

message level versioning is better, but again, what is the value if you still cannot set a relation between messages

Why not set that relationship them with this change then? Even without the relationship I see it been in a better position, but thanks to this talk I am now thinking more an more making name required IF a version is provided. That way we got that relationship.
The options I see on this:

We enforce providing a name IF a version is provided, but not the other way around.I believe is just modifying this PR with the dependencies condition:

 "properties": {
    ...
    "version": {
      "type": "string",
      "description": "A version for the message. Requires a name."
    },
    "name": {
      "type": "string",
      "description": "Name of the message."
    },
    ...
  },
  "dependencies": {
     "version":["name"]
  }

We can highlight that combination, but not enforce it. This is basically just changing the description to something like:
"A version for the message. It can be used in combination with the name to have multiple version of a message"
or we can just say that versioning of events/schemas is not part of the specification, and suggest to people they use the x- attributes.

My preference goes on that order for the following reasons.

If a user start using the version, it would be good to directly guide them to use the name also. Note that the name is only required IF a version is provided.
If feels a bit more clear, and we are guiding the user (making it easier and standard), but they got plenty of freedom to use this or just continue with their happy lives without versioning.
As you said, it allows for providing examples for multiple versions, and deprecating some messages.
I think that combination would work for all user cases, but happy to hear otherwise. If there is a use case that clashes with the version+name, then option 2 becomes into play.
I dislike the option 3 as that means each tool/solution that needs versioning, will do it differently and that would add unnecessary complexity to already complex systems.

What do you all think? I think we are getting somewhere with the conversation, so I do appreciate the time and effort and understand this might take some time.

Hi there,
This is very a very interesting proposal and discussion. I'm really keen to see where it goes, but it's not completely clear to me exactly what issue we're trying to solve with this, I will try to elaborate my confusion below (I hope I don't make it worse!).
First to articulate my understanding and context, to make sure I'm not missing anything as much as anything else:
As I understand AsyncAPI documents they're their to describe what an application that implements the document should do. i.e. it should publish x message to y channel, or receive foo message from bar channel etc.
When an application is implemented it will use a version (application version) of the AsyncAPI document for this, either using some generated core or manually. At the point this is done the application is committing to working with a fixed set of schemas. e.g. the application publishes Dog messages following the Dog schema and this schema might have a version.
If there were more than one version of the schema the publish operations would surely (I am assuming here) only use one version (until the application itself is updated, then it might switch to the next version. One application would not publish two messages using different schemas to the same channel). Whereas a receive operation might have to deal with multiple versions of a schema as there could be multiple applications out there of different versions, and those versions may be compatible or not (i.e. if semver 1.1.1, 1.1.2 and 2.0.0)
Also if we look at OpenAPI which has parallels here. It's interesting that it also does not attempt to solve this problem r.e. requests / responses. In a single version of an OpenAPI document each path has only one definition for its request and response schemas, and within the lifecycle of the document you are expected not to break those schemas so that older clients don't break. If a breaking change is required typically either a /v2/api (or similar) or header is used to allow the client to switch in it's own time before the old behaviour is removed.
Finally in my long preamble (sorry) there is the question of documentation via the AsyncAPI, this is information that does not impact the implementation of the application but is useful meta that can be used to give information to a developer or architect etc. who wants to understand what this application does (description comes to mind)
Given I have bored you to death with talking to myself, onto my confusion:
it seems to me from the issue description, that this is really a problem of documentation via the async API (Please help me understand if I am wrong). As it seems from the use case being described, that you are looking to show people what different versions of messages there are flowing around the architecture and how they vary. And that this cannot sensibly be done just using the application version, which is true.
Additionally I don't see how (from the application developers perspective) knowing the version of the message helps me implement the application, if I am doing a publish I will just use whatever singular schema I have been given in the document for that message. If I am doing a receive I will ensure I handle potentially multiple versions on that channel, where each message could really be two schema versions of the same thing which I can do like:
channels:
  lightingMeasured:
    address: 'smartylighting.streetlights.1.0.event.{streetlightId}.lighting.measured'
    messages:
      lightMeasuredv1:
        $ref: '#/components/messages/lightMeasuredv1'
      lightMeasuredv2:
        $ref: '#/components/messages/lightMeasuredv2'
operations:
  receiveLightMeasurement:
    action: receive
    channel:
      $ref: '#/channels/lightingMeasured'
    messages:
      - $ref: '#/channels/lightingMeasured/messages/lightMeasuredv1'
      - $ref: '#/channels/lightingMeasured/messages/lightMeasuredv2'
components:
  messages:
    lightMeasuredv1:
      name: lightMeasuredv1
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv1'
    lightMeasuredv2:
      name: lightMeasuredv2
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv2'

So it's not completely clear to me what we are discussing is really changing / adding / fixing. And I would really appreciate it if you could help me understand. Looking forward to it!
Also, again, this is a really great discussion

Hi @chrispatmore,
Just to make sure we are all in the same page, the current proposal has evolved to:
Allow for an optional version field that will enforce providing a name when present (that would be my preferred option currently)
Thanks for the long reply and taking the time to read through the messages.
Looking 1st on the articulate section
With regards the application version, I see it more of a document spec version. Nothing to do with my application as otherwise I will need to modify it multiple times a day making it more noisy than useful.
Moving on into the publishing multiple versions of a message, I don't think we can mandate published to only publish one version. We do incremental roll outs meaning we do move from version A to version B slowly, so a published might be publishing version A and B to facilitate that transition. Sometimes is easier to do it in the consumers (allow to consume both) but sometimes it make sense for the producers to do the job.
For the OpenAPI I believe you can use oneOf to provide multiple responses (or accept multiple requests), so you can handle versioning that way if you wish. I think for them it would have been more difficult to standardise this, as there where already various options for versioning. What means consumer/processing applications need to work for x type or y type of versioning, making it pretty difficult to work for all (if any).
I do see this useful for automation of documentation but also to help on helping on the implementation. As having a version can avoid or help understand problems that a version change can introduce.
Now trying to help you understand where I am thinking
From my point of view, I think it would be invaluable to include a version in the messages to give that context to the consumers/processors of the specification. Using your example, a consumer of that asyncapi specification needs to know that the version format is <messageName>v<version> and is in the messageObject key.
For a human this is fine as we know that we have 2 versions of lightMeasured (v1 and v2). For libraries consuming/processing the spec, they will see lightMeasuredv1 and lightMeasuredv2 as different messages that have nothing to do with one another.
Updating your example with the proposal, it should look like this:
channels:
  lightingMeasured:
    address: 'smartylighting.streetlights.1.0.event.{streetlightId}.lighting.measured'
    messages:
      lightMeasuredv1:
        $ref: '#/components/messages/lightMeasuredv1'
      lightMeasuredv2:
        $ref: '#/components/messages/lightMeasuredv2'
operations:
  receiveLightMeasurement:
    action: receive
    channel:
      $ref: '#/channels/lightingMeasured'
    messages:
      - $ref: '#/channels/lightingMeasured/messages/lightMeasuredv1'
      - $ref: '#/channels/lightingMeasured/messages/lightMeasuredv2'
components:
  messages:
    lightMeasuredv1:
      name: 'lightMeasured'
      version: '1'
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv1'
    lightMeasuredv2:
      name: 'lightMeasured'
      version: '2'
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv2'

This will allow applications to understand that both lightMeasuredv1 and lightMeasuredv2 are the same message (with name lightMeasured) but have different versions '1' and '2' (it is a string, so the version can be whatever you want).
This will allow things like:

detecting multiple versions of a message
checking for the differences between schemas/messages
creating changelogs
adding rules for automatically detecting breaking changes (version is just a string)
having a history of event changes
understanding if different versions of messages are going via different channels
etc

I am sure there will be others benefits, the list is just a few things that come to my head.
I think it would be incredibly useful, and should help standardise that area, without it is a free for all and there isn't really a one solution that solves the problem for all.
Consumer applications could use x- to archive this, or messageKey format <message>@<version>, or others.
But that then means each could decide is best to do it a different way and use different formats or x- keys what I think would lead us to something like this:

https://www.explainxkcd.com/wiki/images/6/60/standards.png
Again, extremely useful discussion and happy to take it into a call to see if I am missing something from AsyncAPI and/or how others use asyncAPI that might make this more of a problem than a helpful solution.

Thanks for the reply @IsmaelMartinez, it's certainly helping me to get a handle on this. It definitely seems as though this is looking to define a new standard for how people should document the versions of their messages using AsyncAPI, not because it cannot be done, but because there are too many competing options and it makes it hard to produce useful tooling. However we definitely want to avoid the problem you have indicated of producing just another unhelpful option.
Therefore if we want to do this we need to make sure that what we choose is sensible, suitable an useful in the majority of use cases, accepting that it might not fit everyone's needs or all use cases! Which means I would like to understand the use cases we are trying to tackle a little better.
First can you elaborate on your publishing of multiple versions, I still don't follow the scenario there. As I see it, these are the options you could be indicating, and what I see the problem being (which is why I don't understand the case):

1 publisher publishes 2 messages (1 of each version) to 1 channel

This is duplicating data (which may be acceptable in some scenarios)
The receiver has to cope with both anyway

1 publisher publishes 2 messages (1 of each version) to 2 channels (1 to each, v1 / v2 channel)

This is duplicating data
In AsyncAPI spec, this is two different operations, so as far as one operation is concerned this only deals with one message

1 publisher publishes 1 message (of a version determined by some other runtime factor) to 1 channel

I think this it out of our hands (or should be) as you can't sensibly document the runtime conditions for choosing one over the other in the AsyncAPI document

2 publishers publish 1 message each (at different versions) to 1 channel

I would consider this standard BAU, each could have been built off different revisions (avoiding version here, but a bit on that below) of the whole document with only one operation

2 publishers publish 1 message each (at different versions) to 2 channel (1 to each, v1 / v2 channel)

This is more separated version of above

w.r.t version (application version) the doc states:

Provides the version of the application API (not to be confused with the specification version).

Therefore I think we should assume that most people use it as stated, as the version of their application API, and that if you are changing the API a lot on a daily basis, and publishing those updates every time, then that version will change a lot. I don't think that's a bad thing, just the mark of an active API. It would be interesting to understand the scenarios where the message version changes would / would not impact the application version in this proposal.
Additionally I still don't see this as impacting the actual implementation of the application (this is a bad thing). I can see how it would have a big impact on tooling, all the other things you listed, and be useful for potentially highlighting problems from a version change. But these (IMO) are all documentation / meta, after the document has been coded there would be no difference in the implementation brought about by the introduction of these changes, this is pretty normal, but I think it's important to be clear on it. e.g. using the above short doc example you updated, the behaviour of the application is defined via the different operations, and the links through to the various channels / messages. The inclusion of the new version field (+ required name) does not change this.
Sorry for being so long winded about everything! just really helps me to get clarity, especially when using message threads. I think a call could be good, but I like to make sure I'm joining the call with sufficient context and understanding, and not using people's valuable time getting that in the call.

Hi @chrispatmore, I am still thinking about this, just been busy lately.
Thanks for clarifying the application API and it makes sense. We tend to only make the version matter when we are stable enough, what tends to remove the use of versioning for most services.
We currently use channels as just a generic object. We don't define much in it as we just use EventBridge, and with AWS-CDK IaC you are already doing the definition part in code.
We use versioning and we do phase deployments, parallel runs, shadow runs and the likes. As such, we send messages of different versions in production. Sometimes this can run for a long period as we can also use them to allow to run multiple test cases in parallel, most times this is just for a few minutes while we are deploying a change.
As such, having metadata from the event is almost vital for us. I agree is metadata like the correlationId, and maybe that approach might be a better one.
Another option is to include an optional metadata object like correlationId that is a regex on the message identified and identifies the version. Like that people can optionally use it to identify that from the lightMeasuredv2 the lightMeasured is the name and v2 is the version. Not sure, what do you think?

That's alright I know the feeling!
I think after this discussion and clarity my vote would be for a new meta / metadata section in the message object which can contain version information and / or relation information. Much like was being discussed near the end of https://github.com/asyncapi/spec/issues/697 .
I think that including it in the message key like lightMeasuredv2 is a requirement in order to separate messages and implement the application, but trying to use that string for meta will prove fragile and limiting, and annoying for people who've done it differently.
additionally I think not putting it inside a "metadata" section would imply a level of importance / relevance to the application implementation that I think would cause more confusion or bad practise than the problems it would solve. e.g. I can see someone writing / generating an app that's trying to use some weird envvar or logic to conditionally switch the message version being sent, rather than ensuring their consumers are also updated to handle the new changes / make sure the change are non breaking etc. Basically, the standard should net improve the situation not create more space for confusion
finally w.r.t to schema version, you could extend the argument to include the same new section at that point too. Add in a metadata section that someone can optionally use to provide more info in a standardised way if people want it. But there is no requirement to do so. Any implementation based on the version should continue to use fixed name keys like animalSchemav1 for clear mapping

I try to put an example of what I understand your proposal would be, assuming you only want to move the version into the metadata field:
(only putting the components section as the other part doesn't change)
components:
  messages:
    lightMeasuredv1:
      name: 'lightMeasured'
      metadata:
        version: '1'
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv1'
    lightMeasuredv2:
      name: 'lightMeasured'
      metadata:
        version: '2'
      title: Light measured
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv2'

From my understanding on your proposal we will still need to have a way to identify the message mapping of name/version, but would move the version into a metadata object.
The use of the optional regex would add extra context to the field keys, that people can use as they wish, but will remove the need of having a version and name, as that would be implicit in the keys.
Putting an example of what I mean:
(only putting the components section as the other part doesn't change much - also I haven't tested the regex)
components:
  messages:
    lightMeasured@v1:
      nameVersionRegEx: '^(?<name>[a-zA-Z]+)@(?<version>v\d+)$'
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv1'
    lightMeasured@v2:
      nameVersionRegEx: '^(?<name>[a-zA-Z]+)@(?<version>v\d+)$'
      contentType: application/json
      payload:
        $ref: '#/components/schemas/lightMeasuredPayloadv2'

That solves 3 problems:

The version is in the key field, that in any of the other options we have put needs to change anyway. It is also the more visible part of a message.
People can decide on their regex format they want to use. I guess the limit is the size of the keyfield
The regex would allow us to understand the relationship between events using the name/version mapping.

While I see the point of having a metadata object and a payload (or data) object, I think this is a bigger conversation to be had that would imply moving some of the other fields into it (like name, correlationId, title, contentType, etc).
I would be happy to contribute to that conversation, but I think it would be wise to not make this version conversation a meta(data) conversation as the scope of the later is much bigger, and adding a way to determine a version now, could help drive that conversation depending on how people use it.

For the record, we do use the metadata object in our events, and have the version in it (and name). For reference, we include the following fields:

eventId (aka name) - required
eventVersion (aka version) - optional
traceId (aka correlationId) - optional
timestamp (when the event was generated) - required
tenantId - optional

What do people think? Do you want to move this conversation to be a more metadata/payload separation or keep it into the how do allow for a mapping between event/version? Also, I don't like regex but I see this as the simplest way to solve that mapping, but I am all ears for other options.


Make IntoPyGetter/Setter/DeleterFunc Traits Public

Hey there, I am trying to use RustPython for a Python scripting adapter for a custom scripting system and I had the need to define dynamic getters and setters at runtime that could not be specified as a Fn closure or a fn function pointer, because they needed to be created with extra internal data. That requires that IntoPyGetterFunc and friends had to be public so that I could manually implement them for a custom struct.
For example, here's a super dumb but otherwise impossible to implement getter:
#[derive(Debug)]
struct ComponentGetter {
    key: String,
    value: String,
}

impl ComponentGetter {
    pub fn new(key: &str, value: &str) -> Self {
        Self {
            key: key.into(),
            value: value.into(),
        }
    }
}

impl IntoPyGetterFunc<Component> for ComponentGetter {
    fn get(&self, obj: PyObjectRef, vm: &VirtualMachine) -> PyResult {
        println!("Getting key! — {}", self.key);

        Ok(vm.ctx.new_str(&self.value))
    }
}

Because I'm defining my classes dynamically at runtime, I have to be able to create getters and setters for attributes that I have discovered at runtime, and I couldn't use a closure or a function pointer because I need to be able to pass in extra data to the getter such as the key and value data in the dummy ComponentGetter example above.
Let me know if you have any questions/concerns!

I'm not opposed to making the traits public, but I believe you should be able to do that with a closure - try
fn make_component_getter(name: &str, key: &str, value: &str, ctx: &PyContext) -> PyObjectRef {
    let key = key.to_owned();
    let value = value.to_owned();
    ctx.new_readonly_getset(name, move |obj: PyObjectRef, vm: &VirtualMachine| -> String {
        println!("getting key");
        key.clone()
    })
}

or even -
#[derive(Debug)]
struct ComponentGetter {
    key: String,
    value: String,
}

impl ComponentGetter {
    pub fn new(key: &str, value: &str) -> Self {
        Self {
            key: key.into(),
            value: value.into(),
        }
    }

    fn get(&self, obj: PyObjectRef, vm: &VirtualMachine) -> PyResult {
        println!("Getting key! — {}", self.key);

        Ok(vm.ctx.new_str(&self.value))
    }

    fn into_getter(self) -> impl Fn(PyObjectRef, &VirtualMachine) -> PyResult { // i.e. -> impl IntoPyGetterFunc
        move |obj, vm| self.get(obj, vm)
    }
}

I tried the closure, and it didn't work because taking ownership of values from outside the closure makes the closure FnOnce. I didn't try it the other way, but I think it'd have the same problem.
Either way, I think that the most intuitive way from an API perspective would be to just to implement the trait, anyway.

taking ownership of values from outside the closure makes the closure FnOnce

That's not true, it's not FnOnce if you don't consume the values. Try it, it should work. Thinking about it more, I think I'd actually prefer not to publicize IntoPyGetterFunc/make it possible to implement, that Kind parameter is pretty ugly and it's supposed to represent a function, not an arbitrary type - just like the Fn{,Once,Mut} traits aren't possible to implement for that reason.

Ah, it did work! I tried to copy your code last night, and couldn't get it to compile, but it wasn't because of the closure issue, I was just confused. I'm not sure what I did, but now it works! And I learned something about closures.
That covers my use-case and makes this unnecessary. I agree that the type parameter is really confusing. I had actually misunderstood what it was for when I used it, it just worked so I thought that it was fine.

On that note, actually, what do you think of having a RustPython mdbook? I'm going to likely be spending some time with RustPython as I try to make a scripting solution for Rust programs and I might be able to find the time to write a user-guide on how to use RustPython ( likely in the context of embedding for now ) + maybe some API docs.
I found it a little difficult to figure out how to do certain things and felt like I could use some documentation, but now I'm getting a better understanding and I figure I might be able to write it. :stuck_out_tongue_winking_eye:

Yeah, if you want to write some stuff for it that would be very much appreciated!


delete redundant empty line

Why are the changes needed?

delete redundant empty line
How was this patch tested?

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

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #730 (3de1829) into master (84c07a6) will increase coverage by 0.04%.
The diff coverage is n/a.

:exclamation: Current head 3de1829 differs from pull request most recent head 33ec472. Consider uploading reports for the commit 33ec472 to get more accurate results

@@            Coverage Diff             @@
##           master     #730      +/-   ##
==========================================
+ Coverage   80.49%   80.53%   +0.04%
==========================================
  Files         122      122
  Lines        4748     4748
  Branches      576      576
==========================================
+ Hits         3822     3824       +2
+ Misses        605      604       -1
+ Partials      321      320       -1

Impacted Files
Coverage Δ

...org/apache/spark/kyuubi/SQLOperationListener.scala
97.43% <0.00%> (+5.12%)
:arrow_up:

Continue to review full report at Codecov.

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

thanks, merging to master for v1.3.0


Firebase storage : downloadURL with ascii characters

Flutter doctor
[✓] Flutter (Channel stable, v1.9.1+hotfix.4, on Mac OS X 10.14.6 18G95, locale en-DK)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.39.2)
[✓] Connected device (1 available)
firebase_storage: ^3.0.6
StorageRules is open
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}

Problem:
I am saving the URL internally by setting the https://firebasestorage.googleapis.com/v0/b/ + app name + metadata.path
which results in
https://firebasestorage.googleapis.com/v0/b/app-v2.appspot.com/o/images/Nz92o9x9ys3p2YvRo5Px/0.png?alt=media&token=ad1894f3-9f12-49ce-8261-cd303456aca3
However, the getDownloadurl returns me
https://firebasestorage.googleapis.com/v0/b/minlandsby-v2.appspot.com/o/images%2FNz92o9x9ys3p2YvRo5Px%2F0.png?alt=media&token=ad1894f3-9f12-49ce-8261-cd303456aca3
After 'images' I use a forward slash but the getdownloadurl returns hex character.
This causes a  NetworkImageLoadException was thrown resolving an image codec:
HTTP request failed, statusCode: 400,
If I directly paste the URLs in the browser it is the same behavior.
the one returned from the getdownloadURL loads fine but the one I am generating is not.
Having a slash is creating a problem!!
Also, StorageMetaData.path returns with a slash and not hex characters
Thanks

Hi @shriharip
for what I can see the issue is related to a FlutterFire plugin,
please open the issue in the dedicated github.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you

Hi @shriharip
for what I can see the issue is related to a FlutterFire plugin,
please open the issue in the dedicated github.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you

I agree, but from the github link on flutterfire, I was directed here :). But now I have raised this issue on that repo.


Fix undeclared custom_table variable.

Things To Remember:

Be sure to merge into the right branch. The choices are:

master if your PR runs on the current version of Tableau.
dev-2021.2

You should update at least one of the following:

The changelog of the project you modified.
The root README.md if the PR is a release of the SDK, Connector Packager, or TDVT.
=====

Thanks for the PR, @hawkfish - did you try clicking through the SLA bot workflow? It is showing cla: missing, but they've been having trouble with the bot. Just let me know here if you've already done it.
Thanks!

Hey Luke -
I’m not an employee - I just wrote the original dialect system when I was at Tableau back in the day. I’m hacking on DuckDB these days and I have another client who may be using it with Tableau to visualise a lot of hive-partitioned parquet files so I’m building out an official connector. My email is listed in my GitHub profile @.*** as well as @.***). HTH.
—
Best regards,
Richard Wesley
Our opponent is an alien starship packed with atomic bombs. We have a protractor.
― Neal Stephenson, Anathem

On Apr 24, 2023, at 09:53, Luke Petschauer @.***> wrote:
Thanks for the PR, @hawkfish https://github.com/hawkfish - did you try clicking through the SLA bot workflow? It is showing cla: missing, but they've been having trouble with the bot. Just let me know here if you've already done it.

Hi, Richard,
It's nice to see you here after seeing your name pop up in the source so often 😄 The SLA thing is a workflow Salesforce requires of internal and external contributors to their repos. But like I mentioned, it's flaky, so if someone says they've done it we take them at their word 😄
Thanks again for the bug fix, sorry I missed that commit when I merged this.

Hey Luke -
I’m trying to install a self-signed cert https://tableau.github.io/connector-plugin-sdk/docs/log-entries#import-a-certificate-to-the-trusted-keystore for testing on my MacBook, but there doesn’t seem to be any JRE. It looks like Tableau includes a JRE but I can’t write to that.
Here’s what I’ve been doing:
keytool -genkey -keyalg RSA -alias duckdb_taco -keystore keystore.jks -storepass  -validity 360 -keysize 2048
jarsigner -keystore keystore.jks -storepass  -verbose ~/duckdb_jdbc.taco duckdb_taco
keytool -exportcert -alias duckdb_taco -keystore keystore.jks -storepass  -file duckdb_taco.cer
keytool -importcert -file duckdb_taco.cer -keystore ??? -storepass ??? -alias duckdb_taco
What goes in the blanks?
—
Best regards,
Richard Wesley
I am a magnet for all kinds of deeper wonderment.
— Alanis Morissette, Wunderkind

On Apr 27, 2023, at 16:02, Luke Petschauer @.***> wrote:
Hi, Richard,
It's nice to see you here after seeing your name pop up in the source so often 😄 The SLA thing is a workflow Salesforce requires of internal and external contributors to their repos. But like I mentioned, it's flaky, so if someone says they've done it we take them at their word 😄
Thanks again for the bug fix, sorry I missed that commit when I merged this.
—
Reply to this email directly, view it on GitHub https://github.com/tableau/connector-plugin-sdk/pull/1119#issuecomment-1526697895, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEL66BH7BRD3M3COINABPTXDL3GVANCNFSM6AAAAAAXI2IIMQ.
You are receiving this because you were mentioned.


ensure executor is not shutdown prior to task submisssion

There is a recent issue that has emerged during async evaluations. To repro, you can create a simple custom evaluator whose aevaluate_run implementation contains an inference.
Under these conditions, the _log_evaluation_feedback method will throw because it's trying to submit tasks to a shutdown executor. Specifically we see:
Error running evaluator <wordsmith.evaluation.langsmith.scorers.session_chat_scorer.SessionChatScorer object at 0x122485e10> on run a1247822-b895-45aa-9a15-dcae2a958d7c: RuntimeError('cannot schedule new futures after shutdown')
Traceback (most recent call last):
  File "/Users/rossmcnairn/Library/Application Support/pdm/venvs/wordsmith-8JUPZepZ-wordsmith/lib/python3.11/site-packages/langsmith/evaluation/_arunner.py", line 649, in _arun_evaluators
    self.client._log_evaluation_feedback(
  File "/Users/rossmcnairn/Library/Application Support/pdm/venvs/wordsmith-8JUPZepZ-wordsmith/lib/python3.11/site-packages/langsmith/client.py", line 3983, in _log_evaluation_feedback
    _submit_feedback(
  File "/Users/rossmcnairn/Library/Application Support/pdm/venvs/wordsmith-8JUPZepZ-wordsmith/lib/python3.11/site-packages/langsmith/client.py", line 3969, in _submit_feedback
    _executor.submit(self.create_feedback, **kwargs)
  File "/Users/rossmcnairn/Library/Application<EMAIL_ADDRESS>line 167, in submit
    raise RuntimeError('cannot schedule new futures after shutdown')
RuntimeError: cannot schedule new futures after shutdown

I will openly admit I don't understand why this is happening, but the fix is just to make sure we don't submit tasks to a shutdown executor.
With the minor change, the other path is followed and the code completes successfully.

Thank you for flagging! Will fix in #995 instead
Thank you for your patience :pray:


How to do data distribution?

Question
How to do data distribution? We have A requirement that service A sends data to the gateway, and then the gateway distributes the data to service B and service C

you can use shenyu-sync-data-zookeeper or other middlerware.


Log OOM errors, if possible

Feature Description
I was running gitea in docker, in a small VPS with limited memory. It worked for years, but suddenly I could not clone, and the log showed:

Received signal 15; terminating.

That is SIGTERM. It doesn't say what happened, so it's very hard to diagnose. I had debug logging enabled.
When I increased the memory, it worked again. So the issue was actually an Out Of Memory error.
I assume the SIGTERM is sent by docker; does gitea receive any information other than the signal?
If yes:

it should include "OOM" in the log message to make it easy to diagnose such problems

If no:

just close this issue
OR, maybe include extra info in the log message? Something like Received signal 15; terminating. If you did not stop the container then this could be due to an OOM error.

Screenshots
No response

Is there a log file? Especially the last lines before exit.

50M looks too small for Gitea, I think it should at least 1GB as the limitation.

Golang is not Java. IIRC it's impossible to catch the OOM inside a Go app ....
If there is such an approach, feel free to tell me and I'd like to learn from it .....
https://github.com/golang/go/issues/14162
https://github.com/golang/go/issues/16843
https://github.com/golang/go/issues/29696
https://www.reddit.com/r/golang/comments/9dpxwt/how_to_catch_out_of_memory_panic_in_go/

OOM could appear anywhere, in kernel (seldom nowadays), in docker container program, in docker inside app.
If the Go app itself triggers OOM, then the app itself gets killed. Since Gitea's docker images uses s6 to run gitea web, so if the gitea web gets skilled, the docker container still runs because it still sees s6 service is running.
Maybe it could tell the s6 to run gitea web "always" (just like docker's "always"), even if it exits with error. (just a guess)

We close issues that need feedback from the author if there were no new comments for a month. :tea:

Hmm yup, at the moment I have no idea either. IMO "it is not possible for Golang to log OOM"

Some more details:

Received signal 15 is not only caused by OOM, it could also be caused by some other problems. Only mentioning "OOM" in the message could be misleading.
Received signal 15; terminating. is printed by kernel, so you can't append anything to it.
When there is something wrong, sysop could/should take a look at dmesg, there are more details (also for OOM).
If you want to "catch" the exit code, you need to rewrite the dockerfile by removing the "exec", because Golang doesn't have the ability to catch OOM early.

If you have a feasible approach, feel free to propose a PR.


fix(rust): only schedule heartbeat after elapsed time

A TcpSendWorker currently schedules a new heartbeat for each incoming message. This results in a new context creation every time which consumes a lot of memory because each new context will allocate an mpsc channel. This pressure was alleviated somewhat with commits ac3b8901f4801261dc6b833ac157cfea239e9753 (use 10kb buffer for tcp portal) and 1c6fa8735cb7ceeee73b67a85eb1493782f3a36b (add delay to tcp portal) which resulted in a reduced rate of TcpSendWorker::handle_message calls and hence fewer heartbeat schedules.
This commit keeps track of the elapsed time between handle_message calls and only attempts to schedule a new heartbeat after the interval duration has been reached.

But it's not called if we don't get messages (e.g. tcp connection is alive but not used)

I did not mean to say that idle connections would cause high memory usage, maybe I did not express that well. I observed this with traffic. Here is what my profiler tells me about develop (584ca362a0dbe1795a7b7de4240c1f6516d4309b):

and this is on my branch using the same load pattern:

Well, I don't get what is your suggestion in this PR. We use heartbeats when tcp connection is not actively used to

Keep the connection alive
Detect dropped connections

Your PR makes heartbeats useless, if I read the code right


Adding optional barriers to tic!

@fverdugo ... ready to merge

Codecov Report

Merging #47 (a4fd14d) into master (2a06ba4) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
+ Coverage   91.69%   91.72%   +0.02%
==========================================
  Files           7        7
  Lines        2084     2091       +7
==========================================
+ Hits         1911     1918       +7
  Misses        173      173

Impacted Files
Coverage Δ

src/PTimers.jl
96.38% <100.00%> (+0.33%)
:arrow_up:

Continue to review full report at Codecov.

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

@fverdugo ... this PR is still pending ... please proceed whenever you have time ... thanks!


*_dyn_scalar kernels: Support Float32Array and Float64Array,

Built on https://github.com/apache/arrow-rs/pull/1129 so check that first
Which issue does this PR close?
Re https://github.com/apache/arrow-rs/issues/1113
Rationale for this change
The kernels added in #1115 and others don't support Float32Array and Float64Aray, as @liukun4515 noted in https://github.com/apache/arrow-rs/pull/1115#discussion_r777161312
Also, they currently require the caller to pass in an owned Arc (ArrayRef) rather than &dyn Array which requires unnecessary cloning at the callsite. I discovered this while trying to write tests for Float32/64Array
What changes are included in this PR?
Thanks to @matthermturner's work (and tests!) this PR is fairly simple

Add support and tests for Float32Array and Float64Array
Change the trait bound from Into<i128> to num::ToPrimitive which allows floats and avoids an unnecessary intermediate cast to i128
Remove redundant type checks

Are there any user-facing changes?
API s changed
However, since this code / feature hasn't been released yet so this isn't an API change to released code.

Codecov Report

Merging #1127 (f6c1f4c) into master (89d5273) will increase coverage by 0.07%.
The diff coverage is 92.22%.

@@            Coverage Diff             @@
##           master    #1127      +/-   ##
==========================================
+ Coverage   82.36%   82.44%   +0.07%
==========================================
  Files         169      169
  Lines       49962    50007      +45
==========================================
+ Hits        41152    41229      +77
+ Misses       8810     8778      -32

Impacted Files
Coverage Δ

arrow/src/pyarrow.rs
0.00% <ø> (ø)

arrow/src/array/array.rs
85.14% <84.21%> (-0.11%)
:arrow_down:

arrow/src/array/cast.rs
91.66% <93.75%> (+5.95%)
:arrow_up:

arrow/src/compute/kernels/comparison.rs
92.24% <94.16%> (+2.49%)
:arrow_up:

arrow/src/array/equal_json.rs
89.91% <100.00%> (+0.05%)
:arrow_up:

arrow/src/array/transform/mod.rs
85.56% <0.00%> (-0.14%)
:arrow_down:

arrow/src/datatypes/field.rs
53.68% <0.00%> (+0.30%)
:arrow_up:

arrow/src/array/array_primitive.rs
94.66% <0.00%> (+0.42%)
:arrow_up:

parquet_derive/src/parquet_field.rs
66.21% <0.00%> (+0.45%)
:arrow_up:

Continue to review full report at Codecov.

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

I will review this pr, if it's ready.

I will review this pr, if it's ready.

Thank you @liukun4515  -- the only reason I didn't mark it as ready is I wasn't sure about the change in https://github.com/apache/arrow-rs/pull/1129 -- but that would likely only affect some interior function calls

Merging this in preparation for the 7.0.0 release candidate

Merging this in preparation for the 7.0.0 release candidate

I missed it 😿

I missed it 😿

No worries @liukun4515  -- I would be happy to make any changes / suggestions you may have.


chore: bdd-ghfjxy-import-1587404114 to 0.0.1

chore: Promote bdd-ghfjxy-import-1587404114 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Add cah-william-proemm's file

This pull request adds cah-william-proemm's file to the _post folder.

Renamed file name


Change command args string argument to not split on whitespace

The command args field was modified to be a List in the data model and in the database in order to better support escaping and other issues with bash we've had in the past. However to enable this we were splitting naively on whitespace which could have unintended consequences. This commit reverts that behavior to treat anyone calling the deprecated "string" builder API for the JobRequest to just treat that as a single argument blob. The List builder method still will treat it correctly and join it with a space on a call to get. This should behave as it has in the past with 3 until we have a V4 API. The agent will continue to behave the right way as it only supports List command arguments.

Coverage decreased (-0.005%) to 91.522% when pulling 55d0a866c9899b259b8cf5281b62ca9703f63e76 on tgianos:commandArgBug into 032a01183f97789e24a09980f11a3ffee673640a on Netflix:master.

git am <0001-Example-StringTokenizer.patch.txt


ENH: show progress bar, say how many files were read in, how processing is going

Would be nice to see how things are going
tqdm makes this very easy with python
a bit more logging while the analysis is going would be cool too, just so that I know what's going on, instead of seeing nothing for a minute

tqdm is a super nice thing! Using it when reading a file line by line is not trivial though, but I'm getting there. (Yes, the way I often use it, reading the input file is what takes the most time.)

Progress bars are now enabled by default (only for tasks which take longer than 200ms) and can be disabled with --hide-progress.


Forestry's Squeezer has some issues with the addRecipe function

Good afternoon!
I come forth with an issue after struggling with Modtweaker's Forestry documentation and have a few things to ask and have clarified.  From the wiki:
// Squeezer Recipes
//Time recipe requires (Ticks), InputArray, OutputFluid, OutputStack, Chance for OutputStack //The last two are optional
mods.forestry.Squeezer.addRecipe(4000, [<minecraft:packed_ice> * 4, <minecraft:snowball>], <liquid:ice> * 1000, <Forestry:craftingMaterial:5> * 2, 40);

So I used the following in my own scripts, mods.forestry.Squeezer.addRecipe(100, [<ExtraBees:propolis:2>, <ExtraBees:propolis:2>], <liquid:fuel> * 500);
This results in the error ExtraBees.zs:10 > a method available but none matches the parameters (int, any[], minetweaker.liquid.ILiquidStack)  As Modtweaker is designed now, you MUST specify a secondary drop and the chances.  I've skirted this issue temporarily by adding a propolis with 0% chance.  Is this intended and perhaps the documentation is outdated?
Also, I have one more request for clarification.  The input, in the case of the squeezer, must be an array.  What are we meant to do if we only want one propolis to be used in the squeezer?  I've tried [<ExtraBees:propolis:2>] and [<ExtraBees:propolis:2>, null] with no luck.

The first thing will be fixed in the next version.
I will investigate the second thing.


Make link achor without href styling configurable

@mdo something like
a:not([href]):not([tabindex]) {
  @if stylePlaceholdersLinks {
    color: inherit;
    text-decoration: none;

    @include hover-focus {
      color: inherit;
      text-decoration: none;
    }

    &:focus {
      outline: 0;
    }
  }
}

with stylePlaceholdersLinks turned on by default.
Because a lot of projects

don't use links as placeholders
use a without href or tabIndex

So the change wouldn't affect anyone by default, but if it does some harm  user will be able to turn it off?

a without href nor tabindex is a placeholder link.
This is already heavily discussed in #24140 and #19402 (the PR introducing this snippet). Do you have any relevant use case that could cause any change on this?

a without href nor tabindex is a placeholder link.

No, it's not. Link is a link because it does something. And action can be provided dynamically via javascript.

This is already heavily discussed in #24140 and #19402 (the PR introducing this snippet).

I've already checked them - both doesn't have solution I've offered.
I use Do Somehing a lot, and use href="#" or tabindex= provides nothing like a headache for me.
I think this fix is a good way to settle stuff to supporting placeholders and projects without them

This is the definition itself, as per the specification: a a without href is a placeholder link. You may do something with it, however it's still a placeholder link.
Both issue and PR are asking anyone requring to remove this snippet to answer a question: why aren't you using a button?
The spec is clear enough:

a a tag with href is a hyperlink: it has a target;
a a without target is a placeholder for a potential link (could be the active item in a navigation or a breadcrumb, whatever). It has no target currently but would have if the context changes (like the page). This is to say that it should not be interactive at all, in the current context.

An interactive element without a target has its own element: button. And it can easily be styled as a link since Bootstrap includes a btn-link class.
As of now, and as discussed heavily in both PR and issues, nobody came up with a good reason to use a placeholder link instead of a button. That's why this snippet didn't change for now.
We're not closed to discussion, but would want a relevant use case to consider modifiying this snippet.

This is the definition itself, as per the specification: a a without href is a placeholder link. You may do something with it, however it's still a placeholder link.
Both issue and PR are asking anyone requiring to remove this snippet to answer a question: why aren't you using a button?

Actually I think that problem is that you're appealing to specification that doesn't rely on modern environments. It is true for a html documents, or maybe moderately dynamic websites. If we are talking about modern applications then a is commonly used as a button replacement. Because if we take non-styled elemnts  looks less complicated than button and that's because you can use in more places than button. Even Bootstrap's btn-link uses padding so to use it I have to keep it in mind. So tl;dr is a easier to use and read.

The spec is clear enough:
...

yeah, as I said it does make sense for a old-fashioned apps.

An interactive element without a target has its own element: button. And it can easily be styled as a link since Bootstrap includes a btn-link class.

as I mentioned before

btn-link is not the same as a - it has paddings
<button "btn btn-link btn-link-a">My Link</button> is hard-reading bolierplate to My Link
So if it looks like a a, does things a does then it's definitely a duck a

As of now, and as discussed heavily in both PR and issues, nobody came up with a good reason to use a placeholder link instead of a button. That's why this snippet didn't change for now.
We're not closed to discussion, but would want a relevant use case to consider modifiying this snippet.

Sure, I bet you guys have a lot of things to consider.
But my point is: a lot of people would love to turn off placeholders to be able to write less code.
So if it doesn't break anything why not to implement?

A few things more, then.

So if it doesn't break anything why not to implement?

It would in fact, since in what you're calling "non modern environments", placeholder links would behave visually like links, which shouldn't be the case.

So if it looks like a a, does things a does then it's definitely a duck a

If it doesn't have a href, it doesn't do anything like a link.

It is true for a html documents, or maybe moderately dynamic websites. If we are talking about modern applications then a is commonly used as a button replacement.

Not at all. You may think you're doing things differently, but your end users:

open their browser;
which downloads and renders a html document;
then hope to be able to read content and do something with it.

Whatever you're working on, you're publishing HTML, styled with CSS, with behaviours thanks to JavaScript. All of those have specs. Your "modern applications" works, in fact, in the very same environment than any static HTML page: the web platform, through a web browser, on an OS.
AFAIC, Bootstrap tries to enforce and promote accessibility. Can you tell me how you're handling your links-as-buttons-replacement accessibility?
You may know that placeholder links aren't keyboard operable nor accessible in a links navigation, which is why this snippet resides in Bootstrap.
To make a placeholder link accessible, you'd need to add a few attributes to it: role="button" and tabindex="0". BTW, if it acts like a button, it should be operable using the Space bar besides the Enter key.
So let me try your example again: instead of <button class="btn btn-link p-0"> —please notice that .p-0 unsets paddings— compared to  with (more) custom scripts to make it fully operable.
You may want to go this way, however this is more complex and kinda risky for your users that simply using a button and the relevant classes. But to be honest, if you go this way and make things accessible, you're using a tabindex and not concerned anymore by the above snippet.
So let me ask again: do you have any relevant use case to consider this snippet again?

It would in fact, since in what you're calling "non modern environments", placeholder links would behave visually like links, which shouldn't be the case

That's what I actually want. Because I have to write undo selectors and it has more priority than classes I write. So as was mentioned in ticked you've linked I have to use !important

If it doesn't have a href, it doesn't do anything like a link.

It has onClick which handles navigation change

AFAIC, Bootstrap tries to enforce and promote accessibility. Can you tell me how you're handling your links-as-buttons-replacement accessibility?

I don't. Let's assume that not all projects are accessible by some reasons.
If something changes then I would use things you've suggested, but for bootstrapping I want to write small and readable code fast. And using button instead is not "small and readable"

That's what I actually want. Because I have to write undo selectors and it has more priority than classes I write. So as was mentioned in ticked you've linked I have to use !important

Keep doing so, if you prefer to write useless styles instead of accessible markup. You're still writing code, after all.

It has onClick which handles navigation change.

onclick is an event handler, it doesn't do anything. You do, by hooking some cool functions to this handler. Your script would be exactly the same if you used a button, you'd just have a more accessible markup and wouldn't have to write custom styles.

I don't. Let's assume that not all projects are accessible by some reasons.

Well, we don't.

Emm, I don't offer to remove it. I ask to add an abilty for coder decide what do he needs - placeholders or a quickly accesss.
But instead I see only accusations like "you're doing it wrong". I do it as I prefer to do. Okay, I hope you feel better by judjing and pushing your style.
Have a good day

As I said, we're trying to promote accessibility.
Bootstrap is opinionated, and cannot cover every need nor request. It's already highly customizable thanks to hundreds of variables, and easily overriden by compiling the sources by yourself thanks to Sass.
There's no point to wrap opinionated code blocks with a condition. We're still discussing everything and taking time to understand and answer to everyone, accepting pull request when it looks appropriate and trying to implement what's asked.
As previously said, if anyone has a relevant use case to drop this snippet or make it conditionnal, we'll consider this again.
But for now, we're just like you: opinonated.

Appreciate the discussion here! I’d suggest we raise this in a discussion instead of an issue so folks can give more input and discuss varying options without a specific implementation change to start.
I’m with @ffoodd here overall—every app and site should be accessible by default. I hear you that it’s extra work, but extra work is worth it to the people who need it most.


UX / JavaScript - More elegant LHS menu for docs.openebs.io

Issue type: Feature enhancement
Complexity: Easy
Issue description:
OpenEBS docs site https://docs.openebs.io/ has two menus - Main menu on the LHS and TOC menu on the RHS.
The background color for LHS is white and could look better like shown in the below link.
https://console.bluemix.net/docs/containers/cs_storage_basics.html#kube_concepts

I can take this up.

Please post some screenshots and then send a PR. Thanks for working on this @arshadkazmi42

@arshadkazmi42 I think you should make it full height.
You can also experiment by changing colors and fonts to make it more attractive and send screenshots.

Awesome, let me create a PR right away 👍

@Akash4927 I have created PR against staging branch. Is that fine? Or it needs to be against master branch?

@arshadkazmi42 Thanks for the PR and it's fine. We'll review it soon. :slightly_smiling_face:


Documentation on installation

Hi,
Is there a documentation on how to use this tool along with n8n from scratch ?
Thanks

We'll be updating the docs very soon. I'll keep you posted!
/cc @erin2722

Thanks @ivov
looking forward to create some custom nodes with this tool.

Docs will be finalized next week, but most of them are already available at:
https://github.com/MLH-Fellowship/nodemaker


bumped up to leaflet 1.0.2

closes #315
I checked leaflet v1.0.2 changelog and our example folders. It seems that it is ok to bump up to 1.0.2. But I will appreciate second eyes! 👀

@rfriberg It probably is fine since we are only using style parts of leaflet geocoder mapzen!


[ETHOSN] Add support for Resize

This commit adds support for the resize operator for the Arm(R) Ethos(TM)-N NPU.
cc @lhutton1

This can be merged once CI is green.


provide good docker image for pkg devel

currently, ghactions (and all R actions contained therein) require that the user bring her own docker image, such as rocker/tidyverse, or whatever really.
This makes some sense for random rmd projects (etc.), where the compute environment might well be arbitrary.
It makes a lot less sense for CRAN-bound pkg-dev, where we're usually targeting a pretty well-defined compute environment (CRAN checks)
So it might make sense to default to / standardise on one docker image to run some of the pkg dev actions in. (And this is what the current focus of the project is).
The question is which image (in order of my descending, gut-feeling preference):

one of the r-hub images, because these are (AFAIK?) closely replicating CRAN environments, are pretty slim and are concerned with pkg dev.
One of the rocker images rocker/r-ver.
One of the images maintained by RStudio as part of shinyapps.io or those used in rstudio launcher? (#96). (I know zilch about those).

@jimhester so my suggestion would be:

default to the r-hub images
ask you, or the slack channel which is most suitable.

This would imply:

We limit ghactions to one computing environment (say, debian), and leave the multi-platform testing to r-hub, for now.
We limit ghactions to one r version (say, release), and again, leave the multi-version testing to r-hub.
(We might later add an action to run multiple tests on r-hub as per #71, but maybe not for every commit, but only on release candidates, or triggered by a special commit message or whatever, with all the results from r-hub pasted below the commit or PR).

naturally, this wouldn't apply for some of the "later" actions, such as styler::style_pkg()as in #103, because these can run on pretty much any well-suited docker image we like.

I am not sure the RStudio ones actually exist currently, so I think relying on the R-hub ones seems like the best plan in the short term.

ubuntu-gcc-release it is.

talked with **** (RStudio employee) yesterday and s/he suggested to take a look at

rstudio base img (which does some cool things) (this is open)
imgs used in launcher (apparently open)
and especially: imgs used for linux pkg building in rspm (apparently open)

Mariana-trench deep backlog, my favorite place for issues.

The repo is here FWIW https://github.com/rstudio/r-docker, they are versioned by OS and R version, so you can use rstudio/r-base:3.5-xenial for R 3.5 on xenial etc.


Light mode and dark mode switch

We can add a button on the top bar for switching themes

@origranot
I have already created a PR regarding the dark mode toggle button

@Dev-Code24 I just commented on the PR :)


AWS CodeWhisperer for Visual Studio - self-signed certificate in certificate chain

Describe the bug
Upon installing the AWS Toolkit and setting up CodeWhisperer to provide suggestions, no suggestions appear and the following message appears in the log every time a suggestion is requested with Alt-C:

Info: [2024-03-11T19:57:11.210Z] Recommendation failure: NetworkingError: self-signed certificate in certificate chain

This machine is on our corporate network, which uses self-signed certs for a number of services. Although I'm not certain, I believe the specific one in this case may be for NetSkope.
Many tools have an option to ignore self-signed certificate errors, but the AWS Toolkit settings pane does not appear to offer any such option.
To Reproduce

Launch Visual Studio
Open a code file where you want suggestions
Click the CodeWhisperer icon in the bottom toolbar and sign in
Press Alt-C to attempt to generate a recommendation

Expected behavior
CodeWhisperer allows self-signed certificates and generates code suggestions.
Toolkit Logs
*** Amazon Web Services log ***
AWS Toolkit for Visual Studio
Toolkit Version: <IP_ADDRESS>
Visual Studio: VS Enterprise 2022, Version: 17.9.2

Initializing: Amazon CodeWhisperer Language Client
Launching CodeWhisperer Language Server v0.1.2 from local cache location: C:\Users\****\AppData\Local\aws\toolkits\language-servers\CodeWhisperer\0.1.2\aws-lsp-codewhisperer.exe (Attribution notice for aws-lsp-codewhisperer.exe can be found at: https://aws-language-servers.us-east-1.amazonaws.com/032e3dcc-a411-4917-8785-aada4bfb8642/THIRD_PARTY_LICENSES)
Activating: Amazon CodeWhisperer Language Client
Initialized: Amazon CodeWhisperer Language Client
AWS IAM Identity Center Log in flow started for Credentials: ****
Signed in to CodeWhisperer with Profile:****.
CodeWhisperer's automatic suggestions will be displayed.

*** Amazon CodeWhisperer Language Client logs ***
Info: [2024-03-11T19:52:19.172Z] Codewhisperer server has been initialised
Info: Runtime: Initializing runtime with encryption
Error: (node:39652) NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023.

Please migrate your code to use AWS SDK for JavaScript (v3).
For more information, check the migration guide at https://a.co/7PzMCcy
(Use `aws-lsp-codewhisperer --trace-warnings ...` to show where the warning was created)
Info: Runtime: Registering IAM credentials update handler
Info: Runtime: Registering bearer credentials update handler
Info: [2024-03-11T19:52:19.223Z] Configuration updated to include suggestions with code references
Info: [2024-03-11T19:52:19.223Z] Configuration updated to share code whisperer content with AWS
Info: Runtime: Decoding encrypted credentials token
Info: Decoding JWT token
Info: Runtime: Successfully saved bearer credentials
Info: Runtime: Connection metadata updated
Info: [2024-03-11T19:53:13.974Z] Recommendation failure: NetworkingError: self-signed certificate in certificate chain
Info: [2024-03-11T19:56:56.691Z] Recommendation failure: NetworkingError: self-signed certificate in certificate chain
Info: [2024-03-11T19:56:59.558Z] Recommendation failure: NetworkingError: self-signed certificate in certificate chain
Info: [2024-03-11T19:57:11.210Z] Recommendation failure: NetworkingError: self-signed certificate in certificate chain

Development System (please complete the following information):

Windows Version: 10.0.19045
Visual Studio Version: 2022 (17.9.2)
AWS Toolkit for Visual Studio Version: <IP_ADDRESS>

Thanks for bringing this issue to our attention.  Do you have CAs registered on your Windows workstation for the self-signed certificates?  Can you provide more detail on how you narrowed it down to NetSkope?

Our corporate ones do, yes. The reasons I focused on NetSkope were:

We just recently switched from another product to NetSkope and are still working through various issues with the transition, and
It was the only one that stood out to me in the list of certs as being both self-signed and not part of our corporate trust

The CodeWhisperer feature utilizes NodeJS, which is where the networking error appears to be originating.  As a workaround for now, you could try using NodeJS' own command line args to bypass the check as you were interested in doing in your original post.
You could try to set NODE_OPTIONS=--use-openssl-ca either as a system environment variable or from the context in which you launch Visual Studio.  This may bypass the check and the error.

use-openssl-ca doesn't seem to have any effect.
I'm not sure if this is relevant, but CodeWhisperer / Amazon Q running in VSCode on the same machine works just fine out of the box.

The issue is not replicable in VScode since unlike the AWS Toolkit for VSCode, the CodeWhisperer feature in Visual Studio utilizes a language server with NodeJS runtime.
Based on your previous comment it seems like the cert you are using might be misconfigured, which is probably the reason for the error you are seeing.
Once the cert is correctly configured and trusted, please reach out if you are still running into issues.

We are seeing the same "self-signed certificate in certificate chain" messages in Visual Studio 2022 and our organisation is also using NetSkope. I've checked the certificate, and it looks correctly configured. Locally, the certificate is stored in the Intermediate Certificate Authorities folder.  Is there anything else we should be checking for?  Likewise, the VScode plugin works correctly.

Based on your previous comment it seems like the cert you are using might be misconfigured, which is probably the reason for the error you are seeing.
Once the cert is correctly configured and trusted, please reach out if you are still running into issues.

NetSkope is our corporate VPN/ZTN provider, so this is not something that I as a developer / user have any control over. Would be nice if the VS plugin provided a way to specify a flag (such as in configuration) to ignore these errors.

Another thing to try in addition to the above mentioned workaround is to try setting env variable NODE_EXTRA_CA_CERTS=%path to cert file% either as a system environment variable or from the context in which you launch Visual Studio. This may also help bypass the check and the error.
We'd recommend trying this with a test/dev environment only.

Another thing to try...

This did not have any effect either.
I'm currently in discussions with our NetSec team to see if they have any workarounds for this issue.

I'm not sure if this is an improvement, but I'm not getting the "self-signed certificate" error anymore.
Instead, now I'm getting NetworkingError: unable to get local issuer certificate
I notice that, as of two days ago, the CodeWhisperer language server was updated to 1.0.0, from 0.1.2 that was installed previously.

I'm going to go ahead and close this - with the language server update to 1.0.0, it now seems to honor the environment variables mentioned above.
NODE_OPTIONS = --use-openssl-ca
NODE_EXTRA_CA_CERTS = Path/To/Corporate/Certs

With these both in place, I am able to get CodeWhisperer suggestions now.


Add [Either,Option].orNull. Closes #86.

Okay no worries. I don't have a strong opinion on this one. I noticed an open issue and went for it.
I personally don't see a huge downside to their existence since the type captures the intent but I also appreciate the other side of the coin.


Log Out Auth0 Users

@rob-h-m commented on Mon Sep 09 2019
User Story:
As Connor
I would like to be able to have a personalized experience in the discovery apps
So that I can favorite datasets, create charts, and return to them in the future
Acceptance Criteria:

[ ] Users who logged in with Auth0 can log out
[ ] After logging out, they can log back in

Tech Notes:
Business Value:
1.) Lays the foundation for improved user experience in the OS through personalization
2.) Continued separation between public and restricted datasets
3.) Risk reduction by implementing through external account management services such as Google
Amigos:
@carriebrinkley , @JarredOlson

@abrock-accenture commented on Tue Sep 24 2019
@carriebrinkley @rob-h-m Logout functionality from the UI is already complete.  The only piece that may be missing is the possibility of revoking the user's token so it can no longer be used.  This definitely more work than the 1 point on this card, and we may want to have a conversation about whether this is something we want/need.

Closing as this is already feature parity with LDAP


[BUG] Registry rewrites break fallback to upstream registry

Rancher Server Setup

Rancher version: 2.9.x and prior
Installation option (Docker install/Helm Chart): n/a
Proxy/Cert Details: n/a

Information about the Cluster

Kubernetes version: n/a
Cluster Type (Local/Downstream): Downstream RKE2 or K3s

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom) n/a

Describe the bug
To Reproduce

Cluster Management -> Create -> Custom (or use a node driver, doesn't really matter) -> Give it a name
Registries -> check "Enable cluster scoped..." -> Show Advanced
Registry Hostname: docker.io , Mirror Endpoints: https://registry.example.com
Add Rewrite Config -> Rewrite pattern: ^rancher/(.*) Rewrite replacement: mirrorproject/rancher-images/$1
Create

Result
Note that the cluster nodes fail to come up due to image pull failures in the rancher-system-agent logs, as it cannot pull the image from registry.example.com, and cannot pull the rewritten image name from docker.io.
Expected Result
Rewrite should only be used when pulling from the mirror, and ignored when pulling from default registry endpoint.
Screenshots
Additional context
Issue comes from wharfie, and affects both rancher-system-agent pulling of rancher/system-agent-installer-rke2 and rke2 pulling of rancher/rke2-runtime.

https://github.com/rancher/wharfie/issues/25

This was done with https://github.com/rancher/rancher/pull/47378 merged, ready for testing.

Ticket #47379 - Test Results - ✅
Verified on Rancher v2.10.0-alpha3:

Scenario
Test Case
Result

1.
Downstream K3s with mirrors and rewrites configured
✅

2.
Downstream K3s without mirrors and rewrites configured
✅

Scenario 1 -

Fresh install of Rancher v2.10.0-alpha3
Provision a downstream K3s cluster, v1.30.5+k3s1, with cluster scoped registry enabled and the following configurations set:

Registry hostname: docker.io
Mirror endpoints: https://registry.example.com
Rewrite Config -> Rewrite pattern: ^rancher/(.*)
Rewrite Config -> Rewrite replacement: mirrorproject/rancher-images/$1

Verified - cluster successfully provisions
Verified - rancher-system-agent logs reveal cluster tried to pull from registry.example.com unsuccessfully and then successfully fell back to pulling directly from docker.io; as expected
Verified - /etc/rancher/agent/registries.yaml accurately reflects configured rewrites and mirrors
Verified - bumped system-agent seen and functional: rancher/system-agent:v0.3.10-rc.1-suc

Scenario 2 -

Fresh install of Rancher v2.10.0-alpha3
Provision a downstream K3s cluster, v1.30.5+k3s1, with defaults
Verified - cluster successfully provisions
Verified - bumped system-agent seen and functional: rancher/system-agent:v0.3.10-rc.1-suc


Esperanto letters

Would it be possible to add the Esperanto alphabet letters to one of the layouts? Ideally just the internationalised/English one. The required letters are
'ĉ' [U+0109] - LATIN SMALL LETTER C WITH CIRCUMFLEX
'Ĉ' [U+0108] - LATIN CAPITAL LETTER C WITH CIRCUMFLEX
'ĝ' [U+011d] - LATIN SMALL LETTER G WITH CIRCUMFLEX
'Ĝ' [U+011c] - LATIN CAPITAL LETTER G WITH CIRCUMFLEX
'ĥ' [U+0125] - LATIN SMALL LETTER H WITH CIRCUMFLEX
'Ĥ' [U+0124] - LATIN CAPITAL LETTER H WITH CIRCUMFLEX
'ĵ' [U+0135] - LATIN SMALL LETTER J WITH CIRCUMFLEX
'Ĵ' [U+0134] - LATIN CAPITAL LETTER J WITH CIRCUMFLEX
'ŝ' [U+015d] - LATIN SMALL LETTER S WITH CIRCUMFLEX
'Ŝ' [U+015c] - LATIN CAPITAL LETTER S WITH CIRCUMFLEX
'ŭ' [U+016d] - LATIN SMALL LETTER U WITH BREVE
'Ŭ' [U+016c] - LATIN CAPITAL LETTER U WITH BREVE
Likely these could be added on the pop-out menus as you hold the unmodified versions of the letter keys, as with many of the other accented versions.

I'd greatly appreciate the merging of #525 into this project's master branch.  I have sorely felt the absence of Esperanto special characters, and I would appreciate not having to install the .APK of a fork for this feature.


test_protocol.py doesn't provide 100% test coverage of protocol.py

Since this is now legacy, I care less, and I think I'll remove that code before making this improvement.


Append performance data from taipy-integration-testing instead of replacing the file

When running the perfomance benchmark action, we generate csv files with the performance data. Currently, the files are replaced every time the action is run. We would like to replace the behavior and only append the data into a file on azure blob storage, so it would be possible to track the performance over time.

https://docs.google.com/document/d/1tyeOaKDzP5PDrRdgBC5y1SOnQGe8f0Nf0BaE4p7m38I

@joaoandre-avaiga I believe for this ticket, we only need to add the report file when trigger the benchmark. In particular:
ScenarioPerfBenchmark(github_sha: str, entity_counts: list[int] = None, report_path: str = None) has attribute report_path set to None. We just need to provide a report path to initialization and this ticket will be solved.

@joaoandre-avaiga after careful investigation, I don't think we need to make any changes, as the code should know to download the current result, append to the file and push it back up. Should we discuss more on this?


Bump Dependencies #9140714658

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/9140714658

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


The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.

The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.
The tokenizer class you load from this checkpoint is 'LLaMATokenizer'.
The class this function is called from is 'LlamaTokenizer'.
运行generate.sh的时候出现这个问题，不影响运行，但是可能会影响内容生成？怎么解决？

不用解决，我们直接调用的LlamaTokenizer不会有问题，如果用AutoTokenizer才会报错


Argument list too long

Hello!
While setting up the build environment: executing '/nix/store/...-bash-5.1-p8/bin/bash': Argument list too long.
I'm getting this while installing nixos with a presumably large number of files and directories.
How might I go about fixing this?
Thank you kindly for the help!

Do you have more context info? Where is the argument list in question?

All the files here! 😭

It should at least say what it's trying to build before the error message. Can you paste the whole output, even if it doesn't look relevant? Is this using the NixOS or the home-manager module?

NixOS, and I'm just about to restart the install; I'll paste the output in a bit!

Here it is! https://github.com/shadowrylander/shadowrylander/blob/main/tmp

So I invalidated the tarball cache, wiped out the mountpoint's nix directory, and reinstalled; same error.

Well, if that doesn't solve it, I have no idea what the issue is :shrug: How did you fetch the branch?

fetchGit; I'm currently trying again from a fresh install medium instance.

Well that didn't work...

YES! YES IT WORKS! THANK YOU SO MUCH!


first-timers-only: Add test to make sure optional words don't match the wrong word

first-timers-only
This issue is tagged first-timers-only. It is only for people who have never contributed to open source before, and are looking for an easy way take their first steps.
Thank you for your help :heart:
The Issue
The test specs do not currently test to make sure commands with optional words or phrases (e.g. annyang.addCommands({'Time for some (thrilling) heroics': myFunction});) only match sentences with exactly those words, or without them (e.g. 'Time for some (thrilling) heroics' should match only these two options: 'Time for some thrilling heroics' or 'Time for some heroics', but not 'Time for some gorram heroics'
The tests described inside describe("annyang.addCommands", function() {…}); in test/spec/BasicSpec.js include a number of tests for other uses of addCommands(), and should be used as a template for your code.
Add a test spec that tests that the following code matches the correct commands only: annyang.addCommands({'Time for some (thrilling) heroics': function() {}});
It should be very similar to the test spec for it('should match commands with optional words when the word is in the sentence')
Contributing to annyang

[x] Fork the repository from the annyang GitHub page.
[x] Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/annyang.git
[x] Make sure you have node.js and npm installed on your machine. You can use this guide for help.
[x] Install all of annyang's development dependencies with npm. $ cd annyang; npm install
[x] Run grunt to make sure everything runs smoothly $ grunt
[x] Code, code, code.
[x] Run $ grunt after making changes to verify that everything still works and run the build process. Alternatively, you can just run $ grunt watch once, and leave that process running. It will continuously run all the tests and build the files every time you make a change to one of annyang's files. It will even beep if you make an error, and help you debug it.:+1:
[x] Before committing your changes, the last step must always be running $ grunt. This makes sure everything works, and all files are kept up to date with your changes.
[x] Once you've made sure all your changes work correctly, and committed all your changes, push your local changes back to github with $ git push -u origin master
[x] Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/annyang) and create a pull request for your changes.
[x] Makes sure your pull request describes exactly what you changed and references this issue (just include the issue number in the title like this: #49)

About the tests
annyang is tested using Jasmine.
BasicSpec.js contains a series of spec groups (e.g. describe('a spec group', function() {})) which each contain 1 or more specs (e.g. it('should do stuff', function() {})). Some of the spec groups also contain some code which runs before each spec (beforeEach(function() {})).
To simulate Speech Recognition in the testing environment, annyang uses a mock object called Corti which mocks the browser's SpeechRecognition object. Corti also adds a number of utility functions to the SpeechRecognition object which simulate user actions (e.g. say('Hello there')), and allow checking the SpeechRecognition's status (e.g. isListening() === true).

Can I take this? I'll be able to complete this in a couple of days (I think).

Closed by @Endi1 in #150
:tada:


Interoperability with Webpack import statements

Hello!
First of all, thank you for your hard and amazing work.
The thing is, that Webpack supports more complex import statements than the standard. For example it defines "query" part of the import statements, which looks like this:
import { something } from './path/to/module?query';

The ./path/to/module is an actual filesystem path to a referenced module, however, the ?query is a query part. It allows to configure different loaders for different queries, so the same module could be treated differently in different import statements.
For example import component from './component'; would import the default symbol from the ./component module normally, however, import component from './component?raw'; could be used to load the source code of the ./component file as a string and would put it into component variable (this must be configured in Webpack config). This allows to perform very powerful operations on various files and add it to the resulting bundle. We are using it to generate documentation for example.
The problem is that TypeScript doesn't understand these "extended" import statements and shows errors during type checking. We have to either put @ts-ignore on top of such imports or to use paths configuration option to redirect the compiler to a file containing, e.g.: export default '';.
If TypeScript would support interoperability with extended Webpack import statements it would be very useful in complex projects.
By the way, besides "queries", Webpack also allows to specify loaders inline.
What do you think?

Seems related to https://github.com/microsoft/TypeScript/issues/10988


Where is demo?

Here.
Or here if you prefer an interactive version.

Thanks!
Maybe you can add this links to special chapter in README?

Crap, sorry. 😢 Completely forgot about this.
Added and released as v3.0.2. 👍 Thanks!

Great!


fix missing .yaml, fix yaml parsing due to "step" in current temp, fix eco/comfort mode

Note - I realized this was an issue after I updated to latest tuya-local. I suspect perhaps you kept the file non-yaml due to the issues below so feel free to delete this PR if you have other fixes in mind.
Fixes for:

missing .yaml extension
yaml parsing due to "step" in current temp
eco/comfort mode not being reflected in HA or controllable

I've fixed these issues.


[Refactor] Pages folder rename

Change this folder name examples to Pages, We're refering to this folder path:  schooler/src/views/examples/
Change all the import paths throughout the repository wherever these components are imported
The app should work just like before - it's just a refactor

@meet59patel I want to work on this issue.


fixed Duplicate Symbol Error (linker command failed with exit code 1)

Merged another pull request that included the same.


Fixed key reference errors in condor.py

Closes #380
Fix two KeyError issues that come up if we use condor_submit rather than jobsub_submit.

Note: This PR should go into both master and 1.2-release branches.


Allow user additions to bashrc in web container

Is your feature request related to a problem? Please describe.
Coming from https://github.com/beetboxvm/beetbox I have gotten used to have the ll command (short for ls -la) available OOTB when I ssh into the VM. With ddev, I have to type the whole command, which is an annoyance.
Describe the solution you'd like
I would like it if ll worked out of the box when I ssh to the VM.
Describe alternatives you've considered
I can set up the shortcut inside the VM, but having to do this every time I destroy/rebuild a VM is really tedious.

I think we should probably have a directory that auto-mounts if it exists, and have the container's .bashrc include scripts in there. That way every request like this could be resolved by the user.

I changed the title to a more generic solution. I propose that we add .ddev/bash_profile and .ddev/bashrc handling to the container's .bash_profile and .bashrc, so those get included. That way every project can have custom bash setup as needed.

+1 for this please.

From https://github.com/drud/ddev/issues/1459 - host gitconfig would be completely reasonable here also.

@pcambra requested ~/.ssh/config configuration...

Another related request: Keep bash history around.

Related: Request for composer auth file in #1641