NFTView

Issue To Be Solved
A metadata view that encompasses all data of an NFT resource is needed, otherwise we have to rely on hand-made scripts like what's used in Alchemy's NFT endpoint which differs from what folks at .find return. These scripts shouldn't be needed, I should instead be able to ask for a standard view which would contain all information about an NFT that other platforms can then support.
Separately, a complete view is necessary for dapps to support features on their platforms which require on-chain metadata. For instance, suppose there is a marketplace that wants to allow people to make global offers on nfts, allowing any nft to fill the offer so long as it has certain metadata key/value pairs.
(Optional): Suggest A Solution
After some discussion with @bjartek, @bluesign, and @aishairzay, there are a few options for this that I see. First is that we could use the DictView as I have brought up in #73. This would be flexible enough to work, but some concerns were raised about its lack of explanation on the data being shown.
Another option suggested by @aishairzay is to adopt the OpenSea API Metadata Standard as the NftView. Here is what that structure looks like:
{
  "description": "Friendly OpenSea Creature that enjoys long swims in the ocean.",
  "external_url": "https://openseacreatures.io/3",
  "image": "https://storage.googleapis.com/opensea-prod.appspot.com/puffs/3.png",
  "name": "Dave Starbelly",
  "attributes": [ ... ],
}

And attributes are made up of:
{
  "display_type": "number",  # this one is optional
  "trait_type": "Generation", # this is the key name
  "value": 2
}

Using that as the model, our view would look something like this:
pub struct NftView {
    pub let description: String
    pub let externalUrl: String
    pub let image: String
    pub let name: String
    pub let attributes: [NftViewAttribute]
}

pub struct NftViewAttribute {
    pub let displayType: String?
    pub let traitType: String
    pub let value: AnyStruct
}

I think that we can do away with the things already covered in other views here. I'm just leaving them for reference and consistency with the returned format from OpenSea. You could strip away description, externalUrl, image, and probably name as well. In that case, we are just returning attributes in the format OpenSea returns them. This is a model that folks in the NFT community would be familiar with since that's how much of Ethereum's tokenURI results are formatted. Alignment with the broader NFT ecosystem would be a nice plus there.
Lastly, an option from @bluesign was given to support a generic toDictionary function on structs. In which case, a platform could grab all views an NFT supports and translate them to dictionaries. While this approach would not be a view, I am including it here for the sake of completeness of discussions on the issue at hand.
(Optional): Context
Not having a view like this or something like #73 prevent us from making generic metadata-driven features on flowty and on other platforms. We cannot import all view types that we would like to support on a per-collection basis, so something broader would be a nice value-add.

Along with the opensea API metadata standard, I believe it'd be helpful to extend the NftView struct with some additional metadata that is Flow-specific like the following:
`
pub struct NftView {
// original
pub let description: String
pub let externalUrl: String
pub let image: String
pub let name: String
pub let attributes: [NftViewAttribute]
// new
pub let collectionPublicPath: PublicPath
pub let collectionStoragePath: PublicPath
pub let type: Type

}
`
Adding public paths, storage paths, and types will allow third parties to know how to deposit, discover, compare, and retrieve the relevant NFTs.

@psiemens thanks for the thoughts and I absolutely see your point of view here. At the end of the day, I'm more concerned with enabling my use case than I am the structure of any view I'm proposing. I think maintaining modularity while also rolling certain views up into one cohesive one is a compromise I can live with.
The only thing I'm not sure about is whether each of the above options should actually be optional, or if some should be required? External URLs and Display info might not always be relevant, but I think that attributes and collection info are basically the underlying key pieces of data that this issue is meant to address. For that reason, in my opinion they should be required.

I think that attributes and collection info are basically the underlying key pieces of data that this issue is meant to address. For that reason, in my opinion they should be required.

Yeah that makes sense. I made all the fields optional in that sketch because I wasn't sure what the behaviour should be of one of the view wasn't present.
I guess if attributes is required, the BaseNFTViewsV1 could just return an empty attributes list.
But if collection is required and the Collection view isn't defined by the NFT, should the getBaseNFTViewsV1 function fail? That might be the right behaviour, as it would encourage developers to make sure they meet the minimum requirements for this use case.

Circling back to this (apologies for the delay). @psiemens I like what you've highlighted above a lot, I think my only exception with it is that Collection should not be optional. To dig into why, I think the best way to frame that is what each of these pieces of the View would be for:

Display - How to show the NFT. There are placeholders and fallbacks all the time. For instance, without a display you would probably do CollectionName #ID. For instance, Flunk #8210. I can supplement a missing display with a pretty straightforward option.
ExternalURL - Backlinks. Missing this isn't the end of the world, it just means that a dapp can't give you a backlink to what site "owns" this collection.
Attributes - Metadata on an NFT. My nitpick to this one is that I'd rather just flatten that view out and not have to do view.attributes.attributes and instead just make it pub let attributes: [NftViewAttribute]? on the top-level view. When I think about the worse case here (there are no attributes), that is a perfectly valid use-case. All it means is I don't show any on my dapp. It's the same as attributes being null. An NFT doesn't need to have any to be valid, it's just uncommon that this would be the case. I realize this one might be contentious, it is mostly a nitpick; definitely open to suggestions/dissent on this one!
Collection - Information about how to access this item. After thinking on this a while, this is the most important piece of the entire view. It tells me how to reach the NFT itself whether that's public or private. Without this information, the NFT is actually not usable (without manually researching what those paths might be). On that basis, I'm curious your thoughts on the following:

pub struct BaseNFTViewsV1 {
  pub let display: Display?
  pub let externalURL: ExternalURL?
  pub let collection: Collection
  pub let attributes: [NftViewAttribute]?
}

In my understanding, collection is not a property of the NFT, but actually it is property of the contract that defines the NFT. [0] I mean NFT doesn't know about where it is stored.
So naming it something like below can be more beneficial:
  pub let defaultCollectionPublicPath: PublicPath
  pub let defaultCollectionStoragePath: StoragePath

[0] https://github.com/onflow/flow-nft/blob/758836c84ece752b3ccb10e96a3d91e5ceeedad3/contracts/ExampleNFT.cdc#L16

My nitpick to this one is that I'd rather just flatten that view out and not have to do view.attributes.attributes and instead just make it pub let attributes: [NftViewAttribute]? on the top-level view.

@austinkline Yup this makes sense to me!
I see your point about collection. @aishairzay just put up a PR that accomplishes this use case and more: https://github.com/onflow/flow-nft/pull/82/files
Let's get some code up! Do you want to put ExternalURL and Attributes into a PR? I can do it if you're busy -- just LMK.

Thanks @psiemens! Happy to pick this up, I should have some bandwidth in the next two weeks to get it going

Hey @austinkline, it looks like @aishairzay may need the Attributes view fairly soon. Do you mind if I put up a draft PR for it?

@psiemens feel free! I'd much rather this get out there than stall who should actually make it

@psiemens submitted an initial PR for the Attributes view:
https://github.com/onflow/flow-nft/pull/87

I think this is a data structure that can be derrived from the other views a resource expose. Making the developers implement this in adition to all the else is just a hassle. Create some code to transform a Metadata.ViewResolver with some views into this resource is IMHO a way better option.

@bjartek Are you referring to the Attributes view or the larger NFTView proposed above?

In this issue I am refering to the NFTView. In the other one where I just commented I am referring to the Attributes view.

A factory to make the NftView is a pattern that we could definitely do, I'm not as concerned with that. This is all about the uses cases I'm trying to enable and we definitely don't need people making it themselves if that's the pattern we want to establish

Closed the attempted PR #87. I will circle back to this later.

Thanks @austinkline, I'm just catching up on this. Will also circle back once I've thought about it a bit more.

Picking this back up. Talked with @bluesign and @bjartek about this offline for quite a while. Here are some general asks pertaining to the Attributes view and the larger NftView:

Make the ExampleNft a more verbose showcase of this view and actually use metadata like we are talking about here, it would exclude name/description potentially.
Show what implementing this could mean for TopShot, provide factory methods to assist in less code being needed for collections to implement
Can we enforce that this view (or nftview) must be implemented (sounds like this is up for debate)
How to engage with dapper and ensure they would adopt this, Attributes/NftView are only useful if we can be sure that it would be adopted everywhere.

@psiemens any thoughts on the above? 1-3 I can take on myself but 4 not so much 😄
Separately, I think there is some miscommunication about what is being proposed and why it is useful/needed. This ticket is proposing two new views:

Attributes - A way to represent the underlying metadata or an item. This would replace views like TopShot's TopShotMomentMetadataView so that we can standardize what types are being vended from all these different collections set to come out once permission-less deployment is enabled at our June 15th spork.
NftView - A rollup view containing other views all in one. Think of this as a replacement for the Alchemy response format that many people rely on right now.

To reiterate, we have a few use cases here which I would like to see brought together. Let's start with Attributes. An Attribute really is a wrapper around a single key-value pair and tells you:

What is the value?
What is the name of the value?
How should I show this value? (Optional)

The last piece, information about how to show a value, is the key part here for why it is different than another {String: AnyStruct} dictionary. Some pieces of metadata are more useful when contextualized with an additional disclaimer.
Take, for example, an attribute that represents the time in which the item was minted. Most likely, that attribute is going to be the block timestamp accessible to us in cadence and will be a number. So, instead of showing a number as the dateMinted attribute, I can instead set its display type to Date and platforms know to take that number and attempt to parse it differently. So now we've gone from returning
{
  "dateMinted":<PHONE_NUMBER>
}

to
[
  {
    "traitType": "dateMinted",
    "value":<PHONE_NUMBER>,
    "displayType": "Date"
  }
]

Next, it's worth discussing the differentiation between the Attributes view and the NftView and what I think many of us are thinking but we haven't really laid out yet. The NftView is really just a set of "core" views bundled together. At the time of this ticket being made, those core views are what is laid out in the discussion history, although never really explicitly called this. Those are:

Display - What information should I show as short-hand for this item?
ExternalURL - How do I link this item back to its creator(s)?
Collection - Where should the collection this NFT belongs to be located?
Attributes - What metadata exists on this nft and how should I show it?

The above might not be the real set of core views, I'd encourage everyone who is part of this discussion to weigh in on that. What's nice, however, is that Attributes could be used to express additional views that are more accurately expressed as Attributes instead of a core view. For instance, let's say we think SerialView or EditionView should be included but we aren't sure they're core to all NFTs, a collection could elect to contextualize the Serial attribute to not just be a number, but instead be the SerialView itself as the value and mark the DisplayType as Serial. In this way, we can keep our core views consistent while also allowing these additional versions which permit more rich and purposeful expression. This could also help address some concerns expressed by @bjartek and @bluesign about vending data in multiple places. Instead of vending a serial number attribute and vending a Serial view, bring them together and return the Serial view as an attribute when either Attributes or NftView is requested.
To really emphasize an important piece here..

Attributes - What metadata exists on this nft and how should show it?

Other approaches we've discussed for this problem aren't able to solve the contextualized piece of how to show something. A toDictionary primitive has been proposed in #73 but allowing an attribute to tell you how it should be shown is very powerful. It means an NFT collection owner can be the one who decides/customizes how their items will look on a marketplace. A dictionary cannot express this, it would only have the key and value, no display type.
As for the feedback about what would help get @bjartek and @bluesign over the finish line, I will make another pass at it and see about implementing the whole thing. One nice helper function we should do is just have a dictionaryToAttributes function for folks to use who have no special attributes to show. Then there's very little boilerplate code unless you need something special.
Thoughts? Concerns? I'd like to be on the same page here because submitting PRs that way feedback on the PR itself is more about the organization of what we're doing, not the core concept itself.

Hey @austinkline, lets sync up on the NFTView specifically. I'm currently working on a catalog of NFTs on chain to be leveraged by the Alchemy API and am working on something similar to this

Hey @austinkline, lets sync up on the NFTView specifically. I'm currently working on a catalog of NFTs on chain to be leveraged by the Alchemy API and am working on something similar to this

Sure thing @bshahid331, you can find my contact info in my gh profile bio, happy to sync up in whatever way works best for you

Instead of vending a serial number attribute and vending a Serial view, bring them together and return the Serial view as an attribute when either Attributes or NftView is requested.

My only concern here is Attributes should cover all core views. This solution is pretty elegant in my opinion.

Syncing this week, was out of town for the weekend =)

Thanks for following up on this @austinkline!
@bshahid331 is definitely closer to the NFTView discussion than me. I'm curious to hear the result of your conversation.
Attributes view design / purpose
As for the Attributes view, I think it makes sense to include it if these two things are true:

The Attributes view behaves similarly to a SQL view in the sense that it provides another way to view data that may already be defined directly on the NFT or in another view.
The Attributes view isn't a strict requirement for all Flow NFTs in perpetuity. I think there's a strong use case today with collectible NFT sets (where an array of traits/attributes play a huge role in the NFT's value), but I think we should expect a future where NFTs express themselves with more complex data and hopefully make more use of strongly-typed on-chain data structures.

Both points above address my main concern of a lack of on-chain interoperability. If Attributes were to become the ubiquitous way to define all NFT data, then I agree with @bjartek that it may defeat the purpose of the MetadataViews design.
A simple example is a set of Automobile NFTs that defines a vehicleType attribute. Somebody else may then deploy a racing game contract that allows all cars with vehicleType="compact" to enter a special race. It wouldn't be ideal if that Cadence contract had to iterate through the attributes list to find vehicleType -- it's both inefficient and difficult to program. A better solution, IMO, would be to have a domain-specific Vehicle view that defines a vehicleType enum field.
However I then think it's valid for Automobile to also implement Attributes to provide a more generic representation that can be easily consumed by marketplaces, wallets, etc.
Relationship with rarity
I've been following the rarity discussion in #60 and starting to think that it makes sense for each individual Attribute to include an optional rarity field. @bjartek, I saw your implementation in #92, but I prefer to have the rarities defined directly on each attribute.
At first I thought that Attributes and Rarity should be rolled into one, but now I think that the total rarity of an NFT should be separated from the individual rarities of its traits.
But with that in mind, can there be a common Rarity struct that is shared by both? Something like this:
// An NFT can add MetadataViews.Rarity as a top-level view to define the total rarity.
pub struct Rarity {
  pub let score: UFix64?
  pub let description: String?
}

pub struct Attribute {
  pub let displayType: String?
  pub let traitType: String
  pub let value: AnyStruct

  // Rarity can also be used directly on an attribute.
  //
  // This is optional because not all attributes need to contribute to the NFT's rarity.
  pub let rarity: Rarity?
}

Traits or attributes?
Lastly, would it be more accurate to call this view Traits? It's a subtle name change, but I feel like it more accurately captures the predominant use case of this view.

@psiemens Makes sense on the above, appreciate the weigh-in!

The Attributes view behaves similarly to a SQL view in the sense that it provides another way to view data that may already be defined directly on the NFT or in another view.

I would say this is true. We're vending a standardized format for others can consume with some context that otherwise wouldn't have existed on an individual value in a dictionary (like Rarity as you mention later)

The Attributes view isn't a strict requirement for all Flow NFTs in perpetuity. I think there's a strong use case today with collectible NFT sets (where an array of traits/attributes play a huge role in the NFT's value), but I think we should expect a future where NFTs express themselves with more complex data and hopefully make more use of strongly-typed on-chain data structures.

This makes sense. I see the use of this view versus a more strongly typed one as different. If I can use a strongly-types view, I think the implication is that I know the actual type that I'm interacting with. In that scenario, using a strongly-typed option makes sense (and should absolutely be done). Whereas for Attributes (or Traits), it's meant to encapsulate this information without needing to know anything about what type the NFT actually is. In that way, I think these two can co-exist.
In the Automobile example, for instance, a strongly-typed view make sense because I'm making a game for a specific type, so I can tailor my application to that type or its views accordingly. The proposed Attributes/Traits view is more useful for things like marketplaces that support all types of NFTs, not just a specific one. In that way, I agree that this new view should not be seen as a replacement for all views that give metadata, it is to fill a more generic need in a uniform way
Rarity existing on the attribute itself makes sense to me but I also have not been part of the discussion so much. I will need to catch up and circle back to that.

But with that in mind, can there be a common Rarity struct that is shared by both?

If rarity can be specific to individual traits/attributes of an asset, this makes sense to include in my opinion. In that same light, are there other key pieces of optional info that we would want to add or is rarity the only one? @bjartek any thoughts on rarity going here? The main knock against it in my opinion would be that it increases the scope of what this view is used for. At the same time, if rarity on an attribute is part of a complete picture of that piece of data, then it fits the purpose of this view and its component pieces in my opinion.

Lastly, would it be more accurate to call this view Traits? It's a subtle name change, but I feel like it more accurately captures the predominant use case of this view.

Fine by me! No strong feelings between Trait or Attribute from me, happy to accept either

New flow user here. I would be happy with just a url that points to an Open Sea style json. That's super easy to implement and adopt and it would solve a lot of problems in the short term.
My interest is on making games and having all the metadata stored on chain makes things very complicated. I agree it makes sense for immutable metadata though.
Just my 2cents.

@spacepluk thanks for chiming in!
A url option is certainly useful for projects that opt into that model of metadata. I would point out, however, that flow is meant to store data on-chain so you'll get lots of pushback on it being the default. One of the primary value-props of flow is this very ability and it's why the metadata standard isn't just a tokenURI like it is in ethereum.
We could consider adding in an optional tokenURI, but I think I'd rather it be a separate view given how different the implementations would be. Call it OffChainNftView or something?

I really like this latest adition to Rarities in Attributes/Traits. Very well thought out @psiemens  and @austinkline

My interest is in making games and having all the metadata stored on chain makes things very complicated. I agree it makes sense for immutable metadata though.

Once Traits/Attributes is done it would be very possible to create a proxy that could convert all the onChain data into a opensea style json document and serve that.

We could consider adding in an optional tokenURI, but I think I'd rather it be a separate view given how different the implementations would be. Call it OffChainNftView or something?

Alchemy has a tokenURI field, I know that topshot/rarible/sturdy has json metadata stored elsewhere. I think a seperate TokenURI view in that case makes sense.

Syncing from the blockchain to the server could work for some games.  But depending on the speed of the changes in the attributes you'll have many cases where that's just not practical or even possible. Very often you need a highly optimized game server to be the source of truth. In these cases the NFT is just used to track ownership of the game assets and having a url that points to the actual data is a much better solution. Not having a url and standardized json as the lowest common denominator makes things more complicated than they need to be imho.
I'm pretty new to flow, so maybe my take on this is completely wrong, but as a newcomer I can tell you that the current state of metadata is very confusing. Looking at the alchemy repo you can see that every project has their own way of doing things, and there aren't a lot of project using MetadataViews.
I'm just afraid that if the new standard doesn't guarantee that the metadata will be understood across different wallets/markets there's little incentive to change it for people that already have their own solution and we'll just end up with another competing standard added to the list.
I think the url approach has potential to fare better in that respect and it also happens to suit my project best, hehe

@spacepluk

I'm pretty new to flow, so maybe my take on this is completely wrong, but as a newcomer I can tell you that the current state of metadata is very confusing. Looking at the alchemy repo you can see that every project has their own way of doing things, and there aren't a lot of project using MetadataViews.

Yes, this is true. Metadata standards still need to be adopted by folks, and that's going to get easier in a few weeks when people can deploy their own contracts with no assistance needed from the Dapper team. Once that is done, the community as a whole can assist in onboarding collections onto these standards.

I'm just afraid that if the new standard doesn't guarantee that the metadata will be understood across different wallets/markets there's little incentive to change it for people that already have their own solution and we'll just end up with another competing standard added to the list.

The views proposed here on this issue are actually meant to address almost exactly this. It will be composed of other underlying views that answer the questions:

How do I show this nft?
What are its traits and how do I show them?
Where did it come from (external URL)
Where is it supposed to be stored/retrieved?

In a non-standard way, I've been calling these "core" views. That is, these views are the necessary pieces to give a full picture of an NFT. Other views can exist for a specific purpose, but these are the ones that dapps and wallets will look for to know what to do with your asset.
I don't follow on "another competing standard" though. Views are composable, there isn't going to be one single Metadata View that is the only one to ever be relevant. You are meant to be able to ask for a specific one if you want, or maybe the NftView is you need all core pieces of data.

I think the url approach has potential to fare better in that respect and it also happens to suit my project best, hehe

But isn't this a whole new standard you are proposing? A view that points to supplemental data is good, but only doing TokenURIs, in my opinion, is not. It would mean there's no incentive to put data on-chain which is part of what "owning" your NFT on flow means. If a server is the one that contains all the information of an NFT, then theoretically it can also be tampered with or invalidated. That kind of concept has actually happened in the ethereum world with collections that alter the metadata of an asset if it goes against some kind of rule of theirs. A TokenURI would also make one of the two main use cases this view was proposed for (on-chain metadata-driven functionality) impossible.
I feel like my comment above (https://github.com/onflow/flow-nft/issues/74#issuecomment-1136208132) does a fairly good job in laying out why this is needed in the way it's been proposed, is there something specific you think isn't covered?

Come to think of it, beeing able to add a tag to a given Attribute could be useful. But not sure, it is starting to be very complex.

Come to think of it, beeing able to add a tag to a given Attribute could be useful. But not sure, it is starting to be very complex.

What does a tag look like to you? Is it different from displayType? All these additional pieces of data can be optional. If we make a helper function that takes a dictionary and turns it into the no-frills version of the traits view then maybe it's fine?

@spacepluk I totally see your usecase, and having a TokenURI for these kinds of metadata would for sure make sense. Though I still think the core metadata that is not so often updated should be stored onChain.

One usecase we have at .find is beeing able to do something with a selected set of Attributes/Tags. If we use all Tags/Attributes for this then that could end up beeing too much. So if you could then tag a given attribute to say that it could be used to say Filter something. Then that would be useful. But I am not sure. We are streching it here I think.

Makes sense on both counts. I'm not sure the cut-off for when it's too much or not. For instance, why does rarity make more sense than tags to be included? Is there a better way we can be flexible with that somehow?

@spacepluk

Anyway, I appreciate you hearing me out. I understand it's not the typical NFT use-case and maybe this should be a separate proposal but it would be very helpful to have a standard way of encoding off-chain metadata.

A ticket about this is definitely a great place to start!

I'm proposing to follow OpenSea's standard which is widely adopted.

This is meant to emulate those standards while still being true to Flow and the intent of its own patterns for what it's worth. They will differ a little, but should still be familiar in that they share many of the same basic pieces. This intent is called out in the ticket itself, actually. And @bjartek is right that we could definitely build a transformer of some kind that takes our NftView and outputs the OS standard as well

I get off-chain metadata is controversial

The NftView proposed here didn't consider collections which split data on and off-chain. And there are other initiatives out there like Celer who are working on NFT Bridges to allow Flow NFTs on EVMs and vice versa. There is certainly a need for some kind of way to represent off-chain data. Maybe it is a core view we need to include in this proposal. The main pushback from me is about all of the data being off-chain, so apologies if it feels like your need isn't being taken into account. Would something like a supplemental TokenURI view that is taken in addition to on-chain data fit your needs?
Adoption is the next challenge, and your concerns there are shared by lots of us. The metadata standard is predated by quite a few collections, and since deployments require approval from the dapper team, there's a lot of friction when doing upgrades that folks don't want to go through. The deployment friction is set to go away on June 15th, though, when deployments are no longer gated!

Sync'd with @bshahid331 (feel free to share anything I'm leaving out here)
In general, based on what @bshahid331 has relayed, there are lots of folks talking about the same core deliverable of an NFTView. Because of that, the general thought is that we should get the Traits view merged, and then we circle back in a separate discussion purely about what this complete NFTView would be and how it could be implemented. Lots of different platforms have different things in mind there, and if we don't make sure this end-result can satisfy most needs, adoption may be difficult to achieve.
Next Steps:

I will make a new PR for the Traits view (formerly Attributes) probably in the next day or two
Make a new ticket for the NftView. Partly because this ticket has been discussing two different topics, but also because we haven't tried to reach consensus yet about what views are part of the set of "core" views and which are not.

Anyone is free to make the new ticket, but I will create it over the weekend otherwise with as much detail as possible so we can get started discussing it. The longer we wait beyond folks having deployment permissions the more difficult it will be to get community-wide adoption of whatever we settle on
for visibility: @psiemens @bjartek @bluesign

@austinkline thanks again for the context, the dapper review friction is real!
Just a few more points that I hope you can consider before I move this convo somewhere else.

The main pushback from me is about all of the data being off-chain, so apologies if it feels like your need isn't being taken into account. Would something like a supplemental TokenURI view that is taken in addition to on-chain data fit your needs?

The TokenURI would definitely be an improvement, but in the end it boils down to adoption and support across wallets/marketplaces.  So, if in the end if the standard pushes for all on-chain and this is optional we will likely be forced to put it on-chain if we want our NFTs to look like something.
In that scenario, and ignoring the extra complexity of this solution for a game where the actual data is in the game server there are a few extra issues that would arise. For example:

As far as I understand with the current NFT standard on Flow you can't know for sure who owns a specific NFT (e.g: depositing in a collection that is not stored in an account would trigger a Deposit event without an address, and transferring a whole collection doesn't trigger any event). So we would end up with some objects that we can't update even though they might still be affecting the game world, and the on-chain data would be outdated.

Another issue is that on-chain data will always lag behind what's actually happening in the game (e.g. what if the character is dead and the on-chain data can't be updated on time?)

We could maybe put all the metadata in the contract account, but then there's the issue of storage cost which I haven't calculated but it's something that would add to the running-costs and only go upwards.

Having a TokenURI that points to a metadata view of the game state doesn't have any of these issues and it's a lot easier to implement, and that's why I think it's a good minimum default. I totally agree that data should be on-chain when possible (aka. immutable assets) but I think there are some use-cases like the one I'm describing where it's just a bad solution.

Traits are finished! As a reminder, please add discussion to #98 so we can move to the next step which is a single "full picture" view that dapps can use to get key pieces of information they need about an NFT. Once that discussion is somewhat settled, I can start throwing up a PR for it.
As a callout, some of that implementation can be found here which was started by @bshahid331:
https://github.com/onflow/nft-catalog/blob/main/cadence/contracts/NFTRetrieval.cdc#L11

Can this issue be closed?

Sorry! Missed this, I think we are good to close!


Upgrade mac-10 to Xcode 11 or higher

Minimum version of Xcode was bumped to 11.  mac-10 is currently disabled and is running Xcode 10.2 to accommodate various perf tests.  Those gauge tests are now off..

\cc @godofredoc


fix: typo in doc

In this PR, I'm fixing a small typo in README

@yh1224 please review and feel free to merge it if approved :) Thank you!

@DaisukeMiyazaki Thank you!


CORE-5138: Allow lifecycle coordinators to close in any order

Allow coordinators to close in any order by providing an internal interface to skip the isClosed check on events.  This will allow the registrations to cancel themselves without error and means that the ordering of coordinator close shouldn't matter.

@JamesHR3 I think I covered all possible cases of coordinator/registration/registered coordinators.


TruffleSqueakLauncher consumes 100–300% CPU on macOS

Activity Monitor shows about 100–300% CPU taken by TruffleSqueakLauncher after running:
/Applications/graalvm/graalvm-ce-java11-20.2.0/Contents/Home/languages/smalltalk/bin/trufflesqueak
Also the windows movement inside the TruffleSqueak-20.2.0.image is rather slow.
macOS 11.1
MacBook Pro Retina 13 mid 2014, 3GHz Dual-Core i7, 16GB RAM

Unfortunately, this is "normal" behavior. The load should go down after some seconds/minutes but will go up as you do more things in the Smalltalk environment. The reason for this is the Graal compiler "warming up" the environment in the background. You can see the compiler activity by running TruffleSqueak with "bin/trufflesqueak --engine.TraceCompilation".

Unfortunately, this is "normal" behavior. The load should go down after some seconds/minutes but will go up as you do more things in the Smalltalk environment. The reason for this is the Graal compiler "warming up" the environment in the background. You can see the compiler activity by running TruffleSqueak with "bin/trufflesqueak --engine.TraceCompilation".

We've written some of the limitations up in the TruffleSqueak paper and the GraalVM team is very well aware of these issues. There's not much we can do about this at this point, but we are confident that the situation improves in the future.


Add support for Meta Spatial Anchors OpenXR API

https://developer.oculus.com/experimental/spatial-anchors-overview/

@BastiaanOlij Looks like the api is still experimental so it won't make the 1.2.0 release.
Experimental features are not allowed in the store and require adb commands to enable, so we should wait until it's stable before including.

The feature is being developed in the https://github.com/m4gr3d/godot_openxr/tree/dev_spatial_anchor branch.

@m4gr3d if you want, but it's up to you, I think there is nothing wrong to create a draft PR with the experimental functionality and make it clear in the PR description that this is experimental functionality that can't be used yet in production and that the PR will remain draft until such time that the functionality is made official. This way people can start testing it and start providing feedback.
That is assuming off course that now that the spatial logic is publicaly showcases on the Oculus developer website it no longer falls under any NDA or embargo?

That is assuming off course that now that the spatial logic is publicaly showcases on the Oculus developer website it no longer falls under any NDA or embargo?

Yes, it's publicly available so developers can start prototyping and giving feedback. You just can't ship an app with an experimental api to the Meta store.

Yes, it's publicly available so developers can start prototyping and giving feedback. You just can't ship an app with an experimental api to the Meta store.

Then I would recommend creating a draft PR for it so people can provide feedback :) I know atleast two people on the discord who've been hoping this stuff would be implemented :)

Yes, it's publicly available so developers can start prototyping and giving feedback. You just can't ship an app with an experimental api to the Meta store.

Then I would recommend creating a draft PR for it so people can provide feedback :) I know atleast two people on the discord who've been hoping this stuff would be implemented :)

Same, C++ not my language (yet), but happy to support any way I can. Would like to use the SAs in my next game and would hate to have to use Unity for the prototype, much rather would like to use Godot.
Any high-level guidelines would be appreciated or like a to-do with the several components listed, as I have no idea where to begin.

Spatial Anchor is now publicly available, so it'll be incorporate within an upcoming release.

Is this being actively developed for Godot 4? I started hacking together a GDExtension to support XR_FB_scene, XR_FB_spatial_entity, and related extensions for a personal project, was planning to eventually open source / publish if no one else is already on it


Memory corruption triggered by Android client application

https://github.com/tangrams/tangram-es/issues/865
https://github.com/tangrams/tangram-es/issues/864

This issue has not been reproducible for several weeks, we'll consider it resolved.


Update TF google provider version to 4.48

Make the requirement explicit
Submission Checklist

[x] Have you installed and run this change against pre-commit? (pre-commit install)
[x] Are all tests passing? (make tests)
[x] Have you written unit tests to cover this change?
[x] Is unit test coverage still above 80%?
[x] Have you updated all applicable documentation?
[x] Have you followed the guidelines in our Contributing document?

@heyealex at "nit" level, I'd probably have just used the version numbers without an operator. Otherwise, obviously this looks in line with our objective to fix the TPG version for each release of the Toolkit.
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "4.48.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = "4.48.0"
    }
  }


[#6] Remove copyright header from each file

This PR is removing all copyright header from source files. They are not necessary anymore since the project has been released under MIT license.

Thanks @jjorn, I had to remove the SwiftLint file_header rule to solve the issue.

Thanks @jjorn, I had to remove the SwiftLint file_header rule to solve the issue.

Thanks @jjorn, I had to remove the SwiftLint file_header rule to solve the issue.

@JensK611  Please remove file_header under "Rule Configurations", otherwise it will trigger another warning:
Found a configuration for 'file_header' rule, but it is not enabled on 'opt_in_rules'.

Thanks @jjorn, I had to remove the SwiftLint file_header rule to solve the issue.

@JensK611  Please remove file_header under "Rule Configurations", otherwise it will trigger another warning:
Found a configuration for 'file_header' rule, but it is not enabled on 'opt_in_rules'.


Update BICAC Contract address

Official announcement: http://www.b-icac.com/
Project team background:
Bicac expert advisory group has experienced block chain senior technical talents, top professional lawyers in the world, talents in the gaming industry, management talents and business consultants with top experts and consultants in a huge industry.
Bicac's team members are passionate, ambitious, dreamy and capable, adhere to the professional attitude of integrity, professionalism, responsibility and service, and have rich talents in blockchain, software, gambling, finance, media, 17 supply chain and advertising industries. The main project managers have
profound technical background, master the core technology of bicac, and also have rich professional knowledge and excellence The project management ability of Xiu is a strong guarantee for the future landing of BICAC.
Credit founding team: Genesis: founded in 2012, genesis investment has offices in Tokyo, Zurich and New York, focusing on angel investment, venture capital, equity investment, M & A and other fields, actively looking for investment opportunities in Internet and mobile Internet, high technology, intelligent hardware, luxury goods and services, health care and other fields. The investment focuses on Internet, mobile Internet, high technology, intelligent hardware, luxury goods and services, health care, clean energy and other fields that can bring changes in the future.
Project basic information:
BICAC is a distributed credit ecology based on value network, which pertinently applies blockchain technology system to all kinds of business trust scenarios. BICAC can effectively provide customized credit solutions for all kinds of industries existing in the real world and virtual space, relying on high-performance public ownership chain, cross-chain integrated credit system, modular business structure and certificate economy system, reshaping social credit with decentralized value network, and serving the overall situation of the development of human civilization.
Recommended Gas Limit (For ERC-20 project teams) for transaction: 60,000

你好， 这个PR是修改BICAC的合约地址， 旧的logo已经做了灰度处理，新的PR和logo已提交，麻烦审核一下，谢谢！
官方公告：http://www.b-icac.com/


Examples?

Could you add some examples? 👍 :)
How much profit did you got? and which strategy do you recommend?
thanks,

all the documentation and etc. will be provided soon, no free time atm :( i recommend to make an analysis for specific currency pair with all the strategies and you will see which one is actually better for this case, but mostly it's looks like ichimokutrader.com/signals.html


no device with valid ISO found

Hi there,
somehow I'm getting the error message in the title when testing in virtualbox.
Is this expected?
I'm using an autoinstall iso that I have created using proxmox-auto-install-assistant because I want the machines to pxeboot and then get their config via an answer file from a URL they receive via  DHCP option 250.

Probably too less memory?
Initramfs unpacking failed: write error

Oh!
you're right. apparently 4gb was not enough in my test-vm works with 8
thank you! :)


testing pr for preview issues

Description
Issues
Closes
DEV-XXX:
Related
Testing
Automated tests
Manual testing
Screenshots
Additional notes

Sports-Helsinki branch is deployed to platta: https://liikunta-pr732.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://liikunta-pr732.dev.hel.ninja :laughing::tada::tada::tada:


max grab behavior attribute

I have run npm run test:machinima, and this patch passes all machinima tests: no
add property maxGrabBehavior to specify the behavior to follow when maxGrabbers is reached.
Default is what it does now, which is nothing. Also added 'drop' which ends the grab with the the first hand currently grabbing so that the new hand can grab.

This runs up against the same API gap as #124 - the need to alter the super-hands state. I've filed #152 to track this.

What's the different behavior that you're achieving here? The current default settings are designed to enable a smooth hand-to-hand pass. When a second hand starts grabbing, the original hand remains in control until that button is released, then then second hand takes over the grab. For example, watch this machinima test

The desired behavior is to have the current hand holding the object immediately release it instead of requiring the initial hand to release first.
I have an experimental feature in hubs right now that lets an object's grab be a toggle- so that if you grab an object, it ignores the next release, but then drops the object on any future release (this maybe should be a feature moved into the super-hands stack, but it seemed easier to do that on the application side for now *see below). It is a bit awkward to have to grab/release a second time in the first hand to pass the object over.
So I see 3 options here:

fixing this PR and allowing the option to define the behavior in the case of hitting maxGrabbers limit to either require release on the current hand first or not
creating a new PR that allows a "toggleable" grab (which may require option 1. in some form, but maybe not depending on desired default behavior in that case)
dropping this PR and hubs can do this purely application side

I also added an experimental concept that is more closely tied to how our input works, but allows us to specify a "primary" vs "secondary" action in regards to toggling a grab. The idea is that a primary action (e.g. grip button) will always cause the hand to drop on a second grab (in the case of a "toggleable" grab) but a secondary action (e.g. trigger) will only cause grab to start. This ties into the activatable reaction component such that you can, for example, grab a pen with a trigger or grip and be able to "activate" the pen with the trigger without dropping it, then drop it later with the grip.

closing this as I've opted to use a custom reaction-component that copies grabbable's behavior but adds additional functionality (including this).


Log4cxx

Looking to create a release with log4cxx nupack.
We've included the skeleton in choco-packages and have testing compilation with ros2 logging infrastructure when compiling with DEBUG in Windows.
The packages you will want to add for the next release are here:
https://github.com/ross-desmond/choco-packages/releases/tag/2018-12-21-1
(ignore the tag location, that was used before a final merge).
Connected to https://github.com/ros2/rcl_logging/pull/3

I set up a Windows host to try these instructions. I was able to build in Debug configuration but ran into issues building for Release. Also I had to run to get the bus before I could grab any screenshots so this is just a note to say that this is moving forward.
I haven't yet tried to get anything going with msbuild since I don't yet know how to account for the solution changes made using gui config tools. My plan is to vcs the project dir and try to pinpoint config file changes between the before and after states.

Here's a screenshot of the error I encountered building for release.
@ross-desmond is that something you saw and mitigated? I've torn down the environment and set it up twice and hit this error both times.

@nuclearsandwich I just went through the process myself and the "Additional dependencies on rpcrt4.lib" step is apparently configuration-specific. There's a dropdown at the top of the properties dialog - and if you switch over you can add that additional lib dependency for Release as well.

There's a dropdown at the top of the properties dialog - and if you switch over you can add that additional lib dependency for Release as well.

I thought I'd checked that but perhaps not. I'll give it another shot.

I thought I'd checked that but perhaps not. I'll give it another shot.

Scrapped the workspace and tried again. Something wasn't happy but this time it went through. I've built a package but I can't get a test package to pick it up like I do with the others.
I suppose I should try turning it off and on again.

After rebooting (it didn't take that long I've just been context switching all day) I am able to find the log4cxx package via CMake and build a minimal broken example.

:fireworks: The latest release contains this package :fireworks: It hasn't yet been incorporated into the installation instructions as I figured we would wait until we're ready to merge the PR enabling rcl_logging_log4cxx.

Thanks Steven! Is there anything pending/blocking on rcl_logging_log4cxx PR to get these both in to next patch?

@rutvih @nuclearsandwich is away for a few days, so I'll help get the PR across the line.  I've kicked off a CI build over here to see where we stand: https://github.com/ros2/rcl_logging/pull/3#issuecomment-465188973

@mjcarroll Thank you!


Input: set options on mount to work with v-if

When you have a  inside a  the select will parse the child  elements and build the values on CREATE even tho it is not mounted due to the v-if. Since the model hasnt been loaded yet (why the v-if exists), the checkData will notice that there is no value match to the data (doesnt exist yet), then it will null the value. This means that you cannot async load in data to the  without losing your initial value.
Ive moved the setOptions & checkData to mounted to make it redo these steps once the data exists. (i didnt know if i should remove them from created)
Another option would be to remove the checkData value=null, as, when the data loads in (options watch) the setOptions is called, so they exist correctly, but the value is initial value is already lost.

I would suggest that checkData doesnt null the value (its only purpose?) as, it seems weird to set a value, and have it automatically lost. If doesn't match, the selector will be visibly not selecting anything - as the values dont match, then if a value is added which does, it will match. It seems that this feature might be more confusing for dynamic lists

Not sure if I understood your problem, but the select have not problem with async/lazy loading options.
Check this example and if is what you're trying to do:
https://jsfiddle.net/wffranco/8vzv8v1g/

it was only when using the nested  components to define the
options. When you use :options="" it works. I changed to do it this way,
still a bug tho
On 24 December 2016 at 00:16, Willem<EMAIL_ADDRESS>wrote:

Not sure if I understood your problem, but the select have not problem
with async/lazy loading options.
Check this example and if is what you're trying to do:
https://jsfiddle.net/wffranco/8vzv8v1g/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/wffranco/vue-strap/pull/17#issuecomment-268988355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8aNYEw4Mml7BXt8YjF4NhYq0rxazP2ks5rK8m6gaJpZM4LIjDi
.

--
Tony Polinelli


Fix link path in code example for getting started.

Fixes a link path in the code example for getting started. It's currently an absolute link, which would work, except the instructions say to just open the index.html file in your browser. Without running a server the absolute path fails.
Change: look up one directory "../" to find js files. Otherwise, if you directly open index.html in your browser the files won't be found.

I don't think this change is necessary, see https://github.com/webpack/webpack.js.org/pull/789#discussion_r99062362.
But since this is the second PR on paths in "get started", maybe we should clarify the directory structure in the guide.

@simon04 Thanks for pointing that out. I took a shot at clarifying the directory instead.


Add support for deprecating packages

Purpose
This PR introduces the following to support deprecating Ballerina packages.

Introduce bal deprecate command
bal pull : print a warning when pulling a deprecated package
bal push : print error when trying to push a package with a deprecated dependency.

Fixes https://github.com/ballerina-platform/ballerina-lang/issues/39203
Approach

Describe how you are implementing the solutions along with the design details.

Samples
Valid requests
Deprecating a package:
> bal deprecate mynewdil/deprecate_sample:0.1.0 --message "for testing"
mynewdil/deprecate_sample:0.1.0 marked as deprecated in central successfully

Undo package deprecation:
> bal deprecate mynewdil/deprecate_sample:0.1.0 --undo
deprecation of mynewdil/deprecate_sample:0.1.0 is successfully undone in central

Warnings and errors
Pull a deprecated package:
> bal pull mynewdil/deprecate_sample:0.1.0
WARNING [deprecate_sample] mynewdil/deprecate_sample:0.1.0 is deprecated due to : deprecating for testing
mynewdil/deprecate_sample:0.1.0 [central.ballerina.io -> home repo]  100% [====================================================================================================================================] 2/2 KB (0:00:00 / 0:00:00)
mynewdil/deprecate_sample:0.1.0 pulled from central successfully

bal pack with a dependency on a deprecated package
> bal pack
Compiling source
	mynewdil/deppack:1.0.0
mynewdil/deprecate_sample:0.1.0 [central.ballerina.io -> home repo]  100% [====================================================================================================================================] 2/2 KB (0:00:00 / 0:00:00)
	mynewdil/deprecate_sample:0.1.0 pulled from central successfully
WARNING [deppack] mynewdil/deprecate_sample:0.1.0 is deprecated due to : deprecating for testing

Creating bala
	target/bala/mynewdil-deppack-any-1.0.0.bala

Push a package with a dependency to a deprecated package
> bal push
mynewdil/deppack:1.0.0 [project repo -> central] 100% [===================================================================================================================================================] 2108/2108 B (0:00:00 / 0:00:00)
ballerina: unable to push package as the following dependency of the package is deprecated in the registry: mynewdil/deppack:1.0.0

Deprecate with unused flag:
> bal deprecate mynewdil/deprecate_sample:0.1.0 --undo -m "for testing"
warning: ignoring --message (-m) flag since this is an undo request
deprecation of mynewdil/deprecate_sample:0.1.0 is successfully undone in central

Invalid requests
Deprecate command with invalid package(without version):
> bal deprecate mynewdil/deprecate_sample --message "for testing"
ballerina: invalid package. Provide the package with the version.

USAGE:
    bal deprecate {<org-name>/<package-name>:<version>} [OPTIONS]

Deprecate command with invalid package org:
> bal deprecate mynew-dil/deprecate_sample:0.1.0 --message "for testing"
ballerina: invalid organization name. Organization name can only contain alphanumeric values with lower case letters and cannot start with numeric values, org_name = mynew-dil

Deprecate command with invalid package name:
> bal deprecate mynewdil/deprecate-sample:0.1.0 --message "for testing"
ballerina: invalid package name provided. Only alphanumerics, underscores and periods are allowed in a package name and the maximum length is 256 characters, package_name = 'deprecate-sample'

Deprecate command with invalid package version:
> bal deprecate mynewdil/deprecate_sample:xxxx -m "for testing"
ballerina: invalid request received. error occurred finding package: mynewdil/deprecate_sample:xxxx_java11. Matched version is an error

Package not found:
> bal deprecate mynewdil/deprecatesample:0.1.0
ballerina: package not found for: mynewdil/deprecatesample:0.1.0

Trying to undo a package that is not deprecated:
> bal deprecate mynewdil/deprecate_sample:0.1.0 --undo
ballerina: invalid request received. package is not deprecated

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Some error messages in Central side are fixed with https://github.com/wso2-enterprise/ballerina-registry/pull/1984


Hide from taskbar option

Description of the new feature / enhancement
Adding an option to hide PowerToys icon from taskbar.
Scenario when this would be used?
Daily use.
Supporting information
I really like and enjoy to use your soft. PowerToys is must have utilite for every system. But the huge accumulation of icons in my tray really gives me a lot of discomfort. If you don't mind adding an option to hide the icon, I, like many of your other users, will be very grateful to you.
Whatever it is, thank you very much for your software. This is the most convenient solution for a computer that I have come across. Thank you!

/dup #9526


Rename suppressed pylint error to match value expected by 1.5.4.

Suppresses output from pylint 1.5.4 like:
lint runtests: commands[1] | python /home/tseaver/projects/agendaless/Google/src/gcloud-python/scripts/run_pylint.py
Diff base not specified, listing all files in repository.
************* Module gcloud._helpers
I: 28, 0: Locally disabling import-error (E0401) (locally-disabled)
I: 90, 0: Locally disabling unused-argument (W0613) (locally-disabled)
I:100, 0: Locally disabling unused-argument (W0613) (locally-disabled)
I:104, 0: Locally disabling unused-argument (W0613) (locally-disabled)
I:392, 0: Locally disabling unused-import (W0611) (locally-disabled)
I:392, 0: Locally disabling wrong-import-position (C0413) (locally-disabled)
C:392, 4: external import "from pytz import UTC" comes before "from gcloud.environment_vars import PROJECT" (wrong-import-order)

@tseaver Thanks for the fix. I tried to reproduce locally and cannot. What libraries do I need to update to see this error? (I already created brand new tox environments on multiple machines.)

I tried to reproduce locally and cannot

I found it after tox -r failed on that output.  I have no idea why mine would fail and not your (or Travis).

LGTM BTW

Here is a Travis failure:
https://travis-ci.org/GoogleCloudPlatform/gcloud-python/builds/109433029

Yeah I re-ran the main build 3 times because I couldn't repro and was trying to see if it was intermittent


Add LICENSE and NOTICE files

This PR adds a LICENSE file (Apache 2) and a NOTICE file that includes a copyright declaration in the name of the Regents of the University of Michigan (copyright 2015) and notes that portions of the software were developed at DIG.

@zqian -- have a quick look at the PR.  Includes the requisite LICENSE and NOTICE files.


How to use it in Objective-C project?

Hey, Apple has documentations on importing Swift into Objective-C projects and Objective-C into Swift projects: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html

Could you please add a guide on how to set it up? After following Apple's documentation, it's still not working...
Thanks

@williamfs can you be specific about what problems you're having?


Create wiki documentation for Pootle portal

Create a wiki page to advise users about the process for creating an account and contributing translations for DMPRoadmap via the Pootle portal. @sjDCC and i can test when ready, ideally in time for v0.3 release.

Adding screenshot

Screenshot

Screenshot

Screenshot

Wiki page added. https://github.com/DMPRoadmap/roadmap/wiki/Translations

thanks @vyruss - now @sjDCC and I can test it out

@vyruss I will take a look at it too

I've taken a quick look at pootle again and I find it a bit difficult to navigate.
Is there a simple way someone can get a list of all the terms they need to translate and click through these one by one? We maybe need to add a few basic intructions on how to get into and process a translation.
I also noticed that some of the text will need updating (maily static pages e.g. DMP help). We should re-load these once Stephanie and I have agreed a final set.

I've been playing with the Tutorial and can't figure out how to contextualize the words and phrases that need translating, which makes it difficult to provide an accurate translation. This could be related to @sjDCC request above about getting a complete list of terms to translate.

@sjDCC as soon as you enter Translate mode, you can scroll through all the translations using CTRL+down (or +up). You can increase the number of items on screen by going to Settings -> Translation -> Number of rows (adding this to Wiki).
@stephaniesimms we can add contextual tags in our source code which explain the context to the translator. I'll look into this and detail how it can be done to the devs. We'd rather people didn't work on the pofiles directly because it's easy to make the files unusable by missing out a single or double quote.

thanks for the explanation @vyruss
these changes/revisions to the documentation sound good

Context will appear like so (adding to Wiki too)


Add a brief footer with a link to the repo

Of course, we can add to this and include whatever y'all like -- let me know if you would like to include any specifics and I'd love to add them!

Pull Request Test Coverage Report for Build 393

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

Totals

Change from base Build 385:
0.0%

Covered Lines:
371

Relevant Lines:
413

💛  - Coveralls

Does the UIKit add any special visual elements to the page based on this code? If so, can we see a picture in the PR of how it looks?

@schwartzadev did you see this comment?

@1mn yes - I'm having trouble with my environment as of now -- maybe someone else could pull and take a screenshot?

Here's how it looks. Needs styling for sure.

Here's how it looks now

That's not too shabby, actually.

This seems okay to me. We can merge if someone else approves of it as well. @gdude2002, can you look over it?


Camera not working during social backup

User neridoreen reported camera not working during social backup in Fedi Workshop federation even though their front phone camera does work. Will reviewed code and confirmed there is unsafe behavior happening.

This is the wrong repository.


Actionable items without actions - don't display the dots if there are no actions

Codecov Report

Merging #916 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #916      +/-   ##
==========================================
+ Coverage   99.76%   99.76%   +<.01%
==========================================
  Files         282      282
  Lines        7183     7186       +3
  Branches     1759     1762       +3
==========================================
+ Hits         7166     7169       +3
  Misses         17       17

Impacted Files
Coverage Δ

src/components/actionable-item/ActionableItem.tsx
100% <100%> (ø)
: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 aec1ab9...ca5ab3d. Read the comment docs.


Write up documentation on how to install and run

Created basic instructions, will flesh out in more detail in the future.
fff9ea0291d02da51a6a44821382486af89b90d7


does the non commercial license of the Chat model come from the dataset used to finetune?

if so, can you please let us know which ones are problematic. (I mean, only Alpaca ?)
Cheers.

All but Anthropic's HH-RLHF are ChatGPT outputs and hence non-commercially licensed


📌(backend) pin lxml dependency to 5.2.1

Purpose
With the constraint on lxml<5, an error on the collectstatic occured about lxml
and xmlsec libxml2 versions mismatch.
Proposal
Pin lxml to the latest release fix this error.

@lunika you pinned lxml to <5.0.0 because of a segfault (https://github.com/openfun/marsha/pull/2554).
At what step did the segfault happen? Is it still there?
Seems like it may be corrected now (see https://github.com/SAML-Toolkits/python3-saml/issues/389#issuecomment-2069812485)

@wilbrdt the segfault happened when the user was going back from its CAS when logging using shibboleth.


Using monaco workers for language support

Hi,
I'm trying to upgrade from a previous version of the monaco-languageclient.
I'm only interested in the language client and otherwise prefer to load monaco than vscode, especially for languages that we are not supported by vscode at the moment.
To load workers for client-side languages, I previously used:
import type { Environment } from 'monaco-editor/esm/vs/editor/editor.api.js'
import cssWorker from 'monaco-editor/esm/vs/language/css/css.worker?worker'
import htmlWorker from 'monaco-editor/esm/vs/language/html/html.worker?worker'
import tsWorker from 'monaco-editor/esm/vs/language/typescript/ts.worker?worker'
import jsonWorker from 'monaco-editor/esm/vs/language/json/json.worker?worker'
import editorWorker from 'monaco-editor/esm/vs/editor/editor.worker?worker'

and an extension such as: https://www.npmjs.com/package/monaco-graphql which assume some monaco contribs are there.
With the new version of monaco-languageclient this seems to not be possible anymore because my understanding is that it doesn't use monaco but vscode instead.
How can I support those languages as I did previously ? I see there are vscode language default extensions that could support most of the languages except graphql, but it seems to me that it requires textmate and that it's heavier than the usual monaco language support.
Our use-case is for windmill (https://github.com/windmill-labs/windmill) and users close and start editors a lot, as soon as they change nodes in the app or flow editor. Hence, I would prefer a more lightweight situation.
I'm currently stuck unable to upgrade.

Hi,

I'm only interested in the language client and otherwise prefer to load monaco than vscode

You can't really separate monaco from VScode, that's the same things, VSCode is built around monaco

especially for languages that we are not supported by vscode at the moment

I would be surprised there is a language supported by monaco by not VSCode, do you have an example?

To load workers for client-side languages, I previously used:
import type { Environment } from 'monaco-editor/esm/vs/editor/editor.api.js'
import cssWorker from 'monaco-editor/esm/vs/language/css/css.worker?worker'
import htmlWorker from 'monaco-editor/esm/vs/language/html/html.worker?worker'
import tsWorker from 'monaco-editor/esm/vs/language/typescript/ts.worker?worker'
import jsonWorker from 'monaco-editor/esm/vs/language/json/json.worker?worker'
import editorWorker from 'monaco-editor/esm/vs/editor/editor.worker?worker'

It's bundled with the monaco-editor package directly, but with monaco-vscode-api/monaco-languageclient, they are separate packages (@codingame/monaco-vscode-standalone-XXX-language-features and @codingame/monaco-vscode-standalone-XXX-language-features/worker for the... worker)

and an extension such as: https://www.npmjs.com/package/monaco-graphql which assume some monaco contribs are there.
With the new version of monaco-languageclient this seems to not be possible anymore because my understanding is that it doesn't use monaco but vscode instead.

The monaco-editor api is still exposed via the @codingame/monaco-vscode-editor-api package, so anything supposed to work with monaco-editor should work with @codingame/monaco-vscode-editor-api
The only exception is libraries importing internal monaco-editor modules directly, those modules should be whitelisted in monaco-vscode-api (which seems to be the case for monaco-graphql, I'll whitelist them)

How can I support those languages as I did previously ? I see there are vscode language default extensions that could support most of the languages except graphql, but it seems to me that it requires textmate and that it's heavier than the usual monaco language support.

Since a few weeks ago, you can chose to use monaco/monarch languages (If you don't enable theme/textmate services).
The default ones are packaged in @codingame/monaco-vscode-standalone-languages and any package registering a new language should work (in the condition that there is a proper alias from monaco-editor to @codingame/monaco-vscode-editor-api)

Hi @rubenfiszel the following example let's you start the same Langium Grammar DSL example with monarch and textmate grammars: https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/langium/langium-dsl/wrapperLangium.ts
monaco-editor-wrapper can be run in classic mode (monarch/monaco) or extended mode (textmate/vscode). It removes the need for all the boiler-plate code and you can just configure the languageclient.
Check the Configuration section it details which services are loaded in which configuration.

Also, the multi-editor example makes use of the standalone packages @CGNonofr mentioned above.

With https://github.com/CodinGame/monaco-vscode-api/pull/391, I've managed to make monaco-graphql work

Thanks for the super quick responses. I will give it a try this weekend with all this new information!

Ok I've played with it for a few hours and I've hit a few roadblocks.
I am using vite and  have different issues between npm run dev and npm run build.
Some issues I now suspect would be solved by using https://github.com/CodinGame/monaco-vscode-api#if-you-use-vite
except I import custom wasm in our codebase and we now see new errors:
✘ [ERROR] Cannot find package 'windmill_sql_datatype_parser_wasm_bg.wasm' imported from /git/windmill/frontend/node_modules/windmill-sql-datatype-parser-wasm/windmill_sql_datatype_parser_wasm.js [plugin import.meta.url]

    node_modules/esbuild/lib/main.js:1435:27:
      1435 │         let result = await callback({
           ╵                            ^

    at __node_internal_ (file:///git/windmill/frontend/node_modules/import-meta-resolve/lib/errors.js:431:11)
    at new NodeError (file:///git/windmill/frontend/node_modules/import-meta-resolve/lib/errors.js:374:5)
    at packageResolve (file:///git/windmill/frontend/node_modules/import-meta-resolve/lib/resolve.js:1038:9)
    at moduleResolve (file:///git/windmill/frontend/node_modules/import-meta-resolve/lib/resolve.js:1101:20)
    at defaultResolve (file:///git/windmill/frontend/node_modules/import-meta-resolve/lib/resolve.js:1266:15)
    at resolve (file:///git/windmill/frontend/node_modules/import-meta-resolve/index.js:32:12)
    at file:///git/windmill/frontend/node_modules/@codingame/esbuild-import-meta-url-plugin/dist/esbuildImportMetaUrlPlugin.js:16:34
    at requestCallbacks.on-load (/git/windmill/frontend/node_modules/esbuild/lib/main.js:1435:28)
    at handleRequest (/git/windmill/frontend/node_modules/esbuild/lib/main.js:732:17)
    at handleIncomingPacket (/git/windmill/frontend/node_modules/esbuild/lib/main.js:757:7)
    at Socket.readFromStdout (/git/windmill/frontend/node_modules/esbuild/lib/main.js:680:7)
    at Socket.emit (node:events:519:28)
    at addChunk (node:internal/streams/readable:559:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
    at Readable.push (node:internal/streams/readable:390:5)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)
    at Pipe.callbackTrampoline (node:internal/async_hooks:130:17)

  This error came from the "onLoad" callback registered here:

    node_modules/esbuild/lib/main.js:1293:20:
      1293 │       let promise = setup({
           ╵                     ^

    at setup (file:///git/windmill/frontend/node_modules/@codingame/esbuild-import-meta-url-plugin/dist/esbuildImportMetaUrlPlugin.js:8:9)
    at handlePlugins (/git/windmill/frontend/node_modules/esbuild/lib/main.js:1293:21)
    at buildOrContextImpl (/git/windmill/frontend/node_modules/esbuild/lib/main.js:979:5)
    at Object.buildOrContext (/git/windmill/frontend/node_modules/esbuild/lib/main.js:788:5)
    at /git/windmill/frontend/node_modules/esbuild/lib/main.js:2224:68
    at new Promise (<anonymous>)
    at Object.context (/git/windmill/frontend/node_modules/esbuild/lib/main.js:2224:27)
    at Object.context (/git/windmill/frontend/node_modules/esbuild/lib/main.js:2048:58)
    at prepareEsbuildOptimizerRun (file:///git/windmill/frontend/node_modules/vite/dist/node/chunks/dep-whKeNLxG.js:52821:35)

When using npm run build, it is unable to load the workers because it is trying to fetch them at:
http://localhost:3001/node_modules/monaco-editor-wrapper/dist/workers/tsWorker-es.js

which doesn't exist in the dist folders

Also it seems graphql doesn't exist as a standalone vscode-api feature package

I import custom wasm in our codebase and we now see new errors:

How is it imported in your codebase?

Also it seems graphql doesn't exist as a standalone vscode-api feature package

What do you mean? You can either use the graphql VSCode extension or the monaco library now

What do you mean? You can either use the graphql VSCode extension or the monaco library now

I didn't find a package @codingame/monaco-vscode-graphql-default-extension to install, whereas I found the ones for powershell, shellscript, go, etc. Maybe I'm missing something but the monaco-editor had one.

How is it imported in your codebase?

Like this:
import init, {
	...
} from 'windmill-parser-wasm'
import wasmUrl from 'windmill-parser-wasm/windmill_parser_wasm_bg.wasm?url'

init(wasmUrl)

https://github.com/windmill-labs/windmill/blob/863550a91d8380cd18cc750dc63dfa75bdf504bb/frontend/src/lib/infer.ts#L26
Those packages are custom to us (but public) and build by ourselves using wasm-pack: https://rustwasm.github.io/docs/wasm-pack/

Any clue about why the workers are imported from:
http://localhost:3001/node_modules/monaco-editor-wrapper/dist/workers/tsWorker-es.js

when doing a static build ?
I would have expected vite to export those into an assets folder in the dist/build folder and refer to those directly

I didn't find a package @codingame/monaco-vscode-graphql-default-extension to install, whereas I found the ones for powershell, shellscript, go, etc. Maybe I'm missing something but the monaco-editor had one.

Graphql is not a VSCode default-extension, but you can use the vsix-plugin to load the vsix of the vscode-graphql extension (or by the extension gallery view)

How is it imported in your codebase?

Like this:
import init, {
	...
} from 'windmill-parser-wasm'
import wasmUrl from 'windmill-parser-wasm/windmill_parser_wasm_bg.wasm?url'

init(wasmUrl)

Maybe esbuild-import-meta-url-plugin conflicts with that way of importing the wasm asset? what if you use the new syntax for it as well?
init(new URL('windmill-parser-wasm/windmill_parser_wasm_bg.wasm', import.meta.url).href)

Graphql is not a VSCode default-extension, but you can use the vsix-plugin to load the vsix of the vscode-graphql extension (or by the extension gallery view)

What I'm trying to import is:
https://github.com/microsoft/monaco-editor/blob/8503aef01e4f06dff414c15904a1d961e25eb8eb/src/basic-languages/graphql/graphql.ts#L4
so if I understand right it's part of default monaco but not default vscode?

Maybe esbuild-import-meta-url-plugin conflicts with that way of importing the wasm asset? what if you use the new syntax for it as well?

Will try, thanks!

Graphql is not a VSCode default-extension, but you can use the vsix-plugin to load the vsix of the vscode-graphql extension (or by the extension gallery view)

What I'm trying to import is:
https://github.com/microsoft/monaco-editor/blob/8503aef01e4f06dff414c15904a1d961e25eb8eb/src/basic-languages/graphql/graphql.ts#L4
so if I understand right it's part of default monaco but not default vscode?

Oh my bad, you're just talking about the syntax highlighting, not the intellisense, then the package you're looking for is @codingame/monaco-vscode-standalone-languages which includes all monaco basic languages

Any clue about why the workers are imported from:

@rubenfiszel it tries to load the bundled workers that are part of the npm package from a relative location. That is why you can override the basePath. This is especially helpful when you have pure HTML+JS.
The other possibility is to override all required instructions. new Worker(... instructions are then picked up by bundlers like rollup (vite production).

I did another attempt 2 weeks ago but was unsuccessful but also didn't have enough time to investigate why.
Our current setup work perfectly which is why it's not urgent to upgrade. All of our code is open-source: https://github.com/windmill-labs/windmill
I was wondering if you provided any consulting services since our WebIDE is a very important part of our product, and monaco-languageclient is the core of it.
As soon as I have some more cycles, I will come back to it. Thanks a lot for the support and detailed answers so far!

Hi @rubenfiszel TypeFox offers consulting if you want more direct or timely support.
Please use the contact form on our website to get in direct contact with us.
Independently of that I hope that we now reached a state where future updates will not be as disruptive as they were in the past. We will add more examples/verification examples that ensure directly the stack is working.


Add App Store links and new apps

Hi I add these new apps + add App Store links

Thx @iOS6martinaa but the JSON file is no longer in correct format. Could you update ? You can use https://jsonlint.com/ to help
Sent with GitHawk

sorry for me too hard.

can you make this?


Separate mesos master and slave options

There is a conflict between mesos::property resource names when
mesos::master::options and mesos::slave::options are used on same
machine. The file is different since the directory is different but
the resource name is just the key. There is also a potential conflict
between attributes and resources names.
The solution is to add prefix to name like is done for the static
properties. This involves adding parameter to mesos_hash_parser
function.

Well done, thanks!


does not handle different columns or different column order

I have some data in 50 csv files that all have the same columns, but in a different order in some files.
I realize that this more an issue with my data then spark-csv, but what happens is spark-csv doesn't check the header for each file and instead seems to just throw the data into the columns assuming they all have the same header structure.
I don't necessarily expect spark-csv to check all my columns and put them in the right order, as I can imagine that might degrade performance, but I feel like a warning or error would be appropriate here since it severely messes up the data.

Here is an example to clarify what happens:
file1:
NAME,AGE
Bob,31
Alice,45

file2:
AGE,NAME
54,Sam

in the dataframe the 54 goes into NAME and Sam goes into AGE

+1, this would be nice!

+1, noticing same issue


deps : adding all go.mod locations to dependabots monitoring

Signed-off-by: David Dymko<EMAIL_ADDRESS>Description
The current dependabot setup only watches go.mod in /. This will have dependabot also monitor the other go.mod we have in the /tool/src/* folders.
Related Issues
n/a
Testing
Validated this works on a fork of emissary
Checklist

[ ] I made sure to update CHANGELOG.md.
Remember, the CHANGELOG needs to mention:

Any new features
Any changes to our included version of Envoy
Any non-backward-compatible changes
Any deprecations

[x] This is unlikely to impact how Ambassador performs at scale.
Remember, things that might have an impact at scale include:

Any significant changes in memory use that might require adjusting the memory limits
Any significant changes in CPU use that might require adjusting the CPU limits
Anything that might change how many replicas users should use
Changes that impact data-plane latency/scalability

[x] My change is adequately tested.
Remember when considering testing:

Your change needs to be specifically covered by tests.

Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.

You also need to make sure that the entire area being changed has adequate test coverage.

If existing tests don't actually cover the entire area being changed, add tests.
This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!

We should lean on the bulk of code being covered by unit tests, but...
... an end-to-end test should cover the integration points

[ ] I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently.

[ ] The changes in this PR have been reviewed for security concerns and adherence to security best practices.

lgtm...one word of caution. We will want to double check when updating some of these tools that they still work with Edge Stack. This is due to the tight coupling in edge stack  to the tooling in Emissary-ingress. Alternatively, we could also look to see if there are opportunities to reduce this tight coupling.

Specifically, the yq I know is used in Edge Stack. So, it might end up being moot but just again calling it out as something that could cause fits.

@LanceEa another example is golangci-lint which is used in edge-stack. So we should definitely keep an eye on these dependencies. I figured it might be best just to be aware of these dep updates as they crop up.
However, I do agree we should look to see if we can reduce the coupling.


Add 'slash' to cache

Reported:  https://twitter.com/hsablonniere/status/667425018779975680
Seems kinda odd, but I guess not.  Could be 'index.php' or something.
Let me know what you think.

https://bugzilla.mozilla.org/show_bug.cgi?id=1226364

We add a redirect rule on the server as well to avoid duplicate entries and ensure canonical behaviour. What do you think, @darkwing ?

Good point, another PR coming.

Update here:  https://github.com/mozilla/serviceworker-cookbook/pull/126


bug: Toggling dark mode manually

What version of daisyUI are you using?
v4.6.0
Which browsers are you seeing the problem on?
All browsers
Reproduction URL
none
Describe your issue
The component does not support the manual switching mode of tailwindcss.
When switching dark mode manually, if there is a conflict between the system preferences and the manual settings, the manual settings are disabled. For example, if the system preference is dark and light is switched manually, the component style fails.
tailwindcss.config.js
...
darkMode: ['class', '[data-theme="dark"]'],
...

index.html

Page Views

2.6M

21%

With daisyUI, you don't need to use darkMode in Tailwind config, and you don't need to use either dark: prefix or hardcoded colors like bg-slate-700
daisyUI themes manage all the colors automatically. and you don't need extra class name for dark mode.
Read this page: https://daisyui.com/docs/colors/
Or this one for more details: https://daisyui.com/blog/daisyui-colors-and-themes/
Let me know if you have a question.


Create a Simple ABAP CDS View in ADT

Tutorial URL: https://developers.sap.com/tutorials/abap-dev-adt-create-cds-view.html
Test yourself doesn't work, I wrote my code but nothing..Also view has no data, first I thought I do something wrong but I just copy paste code and try again but nothing.

When you say "nothing", what do you mean? What exactly did you do and what exactly happens?

my code and what happened when I run my code

What code did you enter in the Test Yourself space?

@julieplummer20 I think something wrong with my account because when I click any button doesn't work.
I enter " product.product_description"

Hi,

Actually, I was looking for the whole path: sepm_sddl_so_invoice_item.product.product_name
However, I will reformulate the question as multiple-choice.

Did you run transaction SEPM_DG_OIA, SEPM_DG_OIA_NEW or tasklist STC01 -> SAP_BASIS_EPM_OIA_CONFIG  ? I will update the prerequisites accordingly.

Best wishes, Julie.

@dygsylmz Has this issue been resolved?

Thank you for your feedback. We haven't heard from you in a while, so we are closing the issue.
If you still have questions, feel free to reopen the issue.


[NWC WALLET SERVICE] Info 13194 event creation and broadcast

Event that describes the actions the wallet service supports: https://github.com/nostr-protocol/nips/blob/master/47.md

broadcasted both the staging wallet service event and the prod wallet service event


HHH-10532 Prevent NullPointerException + Testcase

Fix for HHH-10532 .
This includes https://github.com/hibernate/hibernate-orm/pull/1271 .

Thanks for the PR. Did you sign the CLA?

Yes I did on February 2016, 20th. Status is still "Awaiting approval by project lead".

Thanks, I'll ask Steve to aprove it.

Thanks for the PR. Applied it upstream.


Add Logger

The logger should actually go in the script that uses the module. Shouldn't go in the module itself


Add new generic function for destructuring EC points

This PR adds a new generic function - EC-DESTRUCTURE-POINT and provides implementation for the existing EC point classes.
Also, it exports the various EC point operations and adds slot readers.

The EC-DESTRUCTURE-POINT function as you wrote it will return the internal representation of points, which is not the regular (x,y) coordinates of a point on the curve.
Internally we're using projective coordinates which make calculations much faster by avoiding point divisions. A single (x, y) point can have many different but equivalent (X, Y, Z) projective coordinates.
Do you really need to know the internal representation of points, or is it the "official" curve coordinates that you are interested in?

Hey @glv2 ,
Thanks for the quick reply!
I have this example JWK public key.
{
    "kty": "EC",
    "use": "sig",
    "crv": "P-256",
    "kid": "test-id",
    "x": "Nyp0YT9NRlY44cULzFiGnWzF_BsaOwyxmsukKkbvuKA",
    "y": "joRM15S51FU8NNwMpN03mndkxNcK_5cTOn8bVEBy9KU",
    "alg": "ES256"
}

In order to decode above key I'm using the following code.
(defun decode-secp256r1-pk (data)
  "Decodes Secp256r1 (NIST P-256) public key from the given plist data.
See RFC 7518, Section 6.2.1 for more details about Elliptic Curve
public keys format."
  (let* ((use (getf data :|use|))
         (alg (getf data :|alg|))
         (kid (getf data :|kid|))
         (kty (getf data :|kty|))
         (key-ops (getf data :|key_ops|))
         (crv (getf data :|crv|))
         (x (getf data :|x|))
         (y (getf data :|y|)))
    (unless x
      (error 'invalid-key :message "Missing X coordinate parameter" :data data))
    (unless y
      (error 'invalid-key :message "Missing Y coordinate parameter" :data data))
    ;; The X and Y coordinates are Base64urlUInt-encoded values
    (let* ((x-octets (binascii:decode-base64url x))
           (y-octets (binascii:decode-base64url y))
           (x-uint (ironclad:ec-decode-scalar :secp256r1 x-octets))
           (y-uint (ironclad:ec-decode-scalar :secp256r1 y-octets))
           (point (make-instance 'ironclad:secp256r1-point :x x-uint :y y-uint :z 1)))
      (unless (and (= (length x-octets) 32)
                   (= (length y-octets) 32))
        (error 'invalid-key :message "Coordinates should be 32 bytes for Secp256r1 key" :data data))
      (list :use use
            :alg alg
            :kid kid
            :kty kty
            :key-ops key-ops
            :crv crv
            :key (ironclad:make-public-key :secp256r1 :y (ironclad:ec-encode-point point))))))

Then on the REPL:
CL-USER> (defparameter *key-plist*
	   (jonathan:parse (uiop:read-file-string #P"/path/to/ec-public-key.json") :as :plist))
*KEY-PLIST*

CL-USER> (defparameter *parsed-key* (decode-secp256r1-pk *key-plist*))
*PARSED-KEY*

Now, in order to encode back the *PARSED-KEY* into JWK format, I need to add x and y coordinates in the resulting JSON.
The only way I could do that so far is if get y using  (ironclad:secp256r1-key-y (getf *parsed-key* :key), then use (ironclad:ec-decode-point :secp256r1 y) in order to get the point.
And finally I could use (ironclad:ec-destructure-point point) in order to get x and y coords, which will then be encoded in the resulting JWK JSON.
Is there another way I should be approaching this, or is this the way to go?
Thanks!

I added ec-make-point and ec-destructure-point functions (5a467eb18475a577cb532b485f2230c65eff7eeb) containing the appropriate coordinate conversions. I also added a modified version of the second patch of this pull request, to export EC-related functions (2da4f5ea6f2638d64b24e4da25b048a115d86308).
So now you should be able to do:
(let* ((coordinates (ec-destructure-point p))
       (x-uint (getf coordinates :x))
       (y-uint (getf coordinates :y))
  ...)

(ec-make-point :secp256r1 :x x-uint :y y-uint)

Could you give it a try to see if something is missing?

Hey @glv2 ,
I'll try it out soon and get back to you.
Thanks!


A way to disable cursor/caret inside the input

First of all, thank you for this neat little component.
I couldn't seem to find a way to disable the blinking cursor/caret inside the input. Would be nice to have an option to disable that.
Thank you.

Hey @martenjurgens , thank you for the idea. I'll include it for you in the next version 🙂

@martenjurgens Done. Please try to update to the latest version 🙂


3.14 field annoation not covered

The following snippet gets counted as 100% coverage under 3.13 and earlier versions, but under 3.14 it is counted as having a missing line:
class X:
    x: int  # <-- not covered under 3.14

python3.14 -m coverage run asdf.py && python3.14 -m coverage combine --quiet && python3.14 -m coverage report --fail-under 100
Name      Stmts   Miss Branch BrPart  Cover
-------------------------------------------
asdf.py       2      1      0      0    50%
-------------------------------------------
TOTAL         2      1      0      0    50%
Coverage failure: total of 50 is less than fail-under=100

Adding from __future__ import annotations causes everything to be counted:
from __future__ import annotations

class X:
    x: int  # <-- covered

Could have something to do with https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-pep649?

This definitely is because of deferred annotations.  I'm not sure what to do here.  The fact is there is code that has not been run. But also, it is likely never to be run, and it's fine that it isn't run.
But it can have errors.  This will be an error if you run it in 3.13:
class X:
    x: inttttt
    y = 1

% python3.13 att.py
Traceback (most recent call last):
  File "/Users/ned/coverage/trunk/att.py", line 1, in <module>
    class X:
        x: inttttt
        y = 1
  File "/Users/ned/coverage/trunk/att.py", line 2, in X
    x: inttttt
       ^^^^^^^
NameError: name 'inttttt' is not defined

In 3.14, it won't error, but it will if you try to get the annotation:
class X:
    x: inttttt
    y = 1

from annotationlib import get_annotations, Format
get_annotations(X, format=Format.VALUE)

% python3.14 att.py
Traceback (most recent call last):
  File "/Users/ned/coverage/trunk/att.py", line 7, in <module>
    get_annotations(X, format=Format.VALUE)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/pyenv/pyenv/versions/3.14.0a3/lib/python3.14/annotationlib.py", line 707, in get_annotations
    ann = _get_dunder_annotations(obj)
  File "/usr/local/pyenv/pyenv/versions/3.14.0a3/lib/python3.14/annotationlib.py", line 842, in _get_dunder_annotations
    ann = _BASE_GET_ANNOTATIONS(obj)
  File "/Users/ned/coverage/trunk/att.py", line 2, in __annotate__
    x: inttttt
       ^^^^^^^
NameError: name 'inttttt' is not defined

btw, I also opened a discussion thread about this: https://discuss.python.org/t/how-should-coverage-py-treat-deferred-annotations/74990

As a user, my feeling is that if the field annotation is considered covered in 3.13 with from __future__ import annotations, then it should also be considered covered under 3.14 without the import.
Here is a naive suggestion. I assume there is a line somewhere to the effect of:
if has_future_annotations_import():
    field_annotation.count_as_covered()

Maybe that could be changed to:
if has_future_annotations_import() or PY_VER_314_PLUS:
    field_annotation.count_as_covered()

All of the annotations are put into code objects called __annotate__, so I can ignore those when looking for executable lines, and the problem is fixed in commit 2d048353b2d1c62f3eee9d82d7ac055229e8e791.

Tested; works. Thanks!

This is now released as part of coverage 7.6.10.


When operating a custom dataset, will it work if I just set config.toml?

Isn't it still not applicable to data such as custom datasets (e.g. credit card fraud detection data)?

It seems to be suitable for tabular data, but is it not suitable for transaction data?

@limhasic  hard to do that, I'm recently on the synthesis of fraud detection transactions, I found that tab-DDPM proposed here can only handle samll feature sets. My trans data includes about 400 features, the training is hard and the generation is not satisfactory.

Would it be possible with data with about 60 columns? The data is from https://dacon.io/competitions/official/236297/overview/description, and since I have difficulty using this repository, I am using tabddpm from synthecity.


tSnowflakeOutput stuck after PUT file on linux

Executing a job containing a tSnowflakeOutput Bulk upload via built with 7.1.1M3 seems to idle for several minutes after PUT file operation when running on linux server.

Execution works fine from within Talend OS DI 7.1.1M3 on Win10 however.

@pteyssier i cannot add issues to jira, perhaps you can do that.
is this already known / reproduceable?


Give custom resources friendly names [Prev: Simplify SqlServerDatabase Resource Type]

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.
Project, Container and Executable resoruces have nice concice names in the Type column of the Resources page (and in the Resource Types filter).

Describe the solution you'd like
It would be nice if SqlServerDatabaseResource (and possibly other resources) could have a similarly concise name.  (e.g. SqlDatabase or SqlServerDatabase)
Additional context
No response

Gonna close this as a dupe of #2595  since we'd ideally address this as part of that work. Great call though - completely agree 💯

Another option is to just make custom resources look nicer with a lil change so we could do that in the meantime

@mitchdenny @davidfowl Where does this name come from? Is it the type name? If so, could a fix be a simple as removing "Resource" suffix from the type name?

We can do that, but it seemed a little aggressive to assume 😄:
https://github.com/dotnet/aspire/blob/47e3e25e51c60627aa5fa9a4bf4aaeaf26402ce2/src/Aspire.Hosting/ApplicationModel/ResourceNotificationService.cs#L348

What is the alternative? Add a ResourceTypeNameAnnotation?

Resources can already set it using WithInitialState


refactor: remove queryFields in QueryObject

SUMMARY
Remove queryFields from formData and queryContext as per discussion in https://github.com/apache/incubator-superset/pull/9962#issuecomment-655791527
Requires https://github.com/apache-superset/superset-ui/pull/862
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A
TEST PLAN
No functional changes, all CI should pass
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #12091 (af20689) into master (655834b) will decrease coverage by 3.80%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #12091      +/-   ##
==========================================
- Coverage   67.46%   63.66%   -3.81%
==========================================
  Files         959      476     -483
  Lines       47245    29370   -17875
  Branches     4630        0    -4630
==========================================
- Hits        31874    18697   -13177
+ Misses      15258    10673    -4585
+ Partials      113        0     -113

Flag
Coverage Δ

cypress
?

javascript
?

python
63.66% <100.00%> (-0.65%)
:arrow_down:

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

Impacted Files
Coverage Δ

superset/cli.py
34.69% <ø> (-0.09%)
:arrow_down:

superset/common/query_object.py
91.59% <100.00%> (+0.07%)
:arrow_up:

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.62%)
:arrow_down:

superset/db_engine_specs/presto.py
69.95% <0.00%> (-12.45%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/utils/celery.py
96.42% <0.00%> (-3.58%)
:arrow_down:

superset/examples/world_bank.py
97.10% <0.00%> (-2.90%)
:arrow_down:

superset/db_engine_specs/postgres.py
97.56% <0.00%> (-2.44%)
:arrow_down:

... and 494 more

Continue to review full report at Codecov.

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

To me the failed cypress tests are causing errors on unrelated PRs. I'll restart a few times to see if they're just flaky.


update instructions

#1193

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

@TrudyHa - PR has been copy edited and is ready for final review. This is based on issue #1193.
Thank you.
cc: @kenwith