Common services based on Tax and Customs Board's open data

AS A Product Owner
I WANT TO have common services based on Tax and Customs Board's open data
SO THAT I could provide tax-related common services based on data provided by a verified third-party
Acceptance Criteria

[ ] All services as separate REST endpoints
[ ] All services provide relevant information about a specific company
[ ] All services provide summarized relevant information
[ ] Queries based on fixed time frame (quarter)
[ ] Service queries can be grouped by EMTAK
[ ] Service queries can be grouped by county

Scope

[ ] #38
[ ] #39
[ ] #40
[ ] #41
[ ] #42

Data schema

[!NOTE]
All services as part of this epic will be based on the following data schema

{
  "mappings": {
    "properties": {
      "registry_code": {
        "type": "text"
      },
      "name": {
        "type": "string"
      },
      "type": {
        "type": "text"
      },
      "vat_register": {
        "type": "text"
      },
      "emtak_field_of_activity": {
        "type": "text"
      },
      "county": {
        "type": "text"
      },
      "national_taxes": {
        "type": "text"
      },
      "labor_taxes_and_payments": {
        "type": "text"
      },
      "turnover": {
        "type": "text"
      },
      "workers": {
        "type": "text"
      }
    }
  }
}

Added an ingest companies pipeline to make sure to filter the data before adding it to open search.
It Currently does the following:

Makes sure that any empty employee field is replaced with 0
Makes sure that employee are converted to integer
Makes sure that any empty national taxes field is replaced with 0
Makes sure that national taxes field is formatted correctly so that for example 100,2 is formated to 100.2
Makes sure that national taxes field is converted to double
Makes sure that any empty paid workforce taxes field is replaced with 0
Makes sure that paid workforce taxes field is formatted correctly so that for example 233,62 is formated to 233.62
Makes sure that paid workforce taxes field is converted to double
Makes sure that any empty revenue field is replaced with 0
Make sure that revenue field is formatted correctly so that for example 300,789 is formated to 300.789
Make sure that revenue field is converted to double

Tax and Custom's Board service
#89


To reduce duplication, consider removing IEntityData

The IEntityData interface mainly duplicates IQuery and IPersister. This is on the borderline of an SRP violation.
Consider changing the entity-related functionality to just a query.

No need to do this, the service does have a lot of methods, it's not unreasonable to bundle it all together. It also has functionality which is specific across the board.


[duplicate] UI incompatible with new bot version

# github.com/go-telegram/ui/datepicker
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:47:31: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.showMain
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:50:31: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.showMain
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:54:45: update.CallbackQuery.Message.Chat undefined (type models.MaybeInaccessibleMessage has no field or method Chat)
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:55:45: update.CallbackQuery.Message.MessageID undefined (type models.MaybeInaccessibleMessage has no field or method MessageID)
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:62:31: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.onSelect
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:66:45: update.CallbackQuery.Message.Chat undefined (type models.MaybeInaccessibleMessage has no field or method Chat)
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:67:45: update.CallbackQuery.Message.MessageID undefined (type models.MaybeInaccessibleMessage has no field or method MessageID)
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:74:31: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.onCancel
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:76:37: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.showSelectYear
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:78:37: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to datePicker.showSelectYear
..\..\..\go\pkg\mod\github.com\go-telegram\ui@v0.2.0\datepicker\callback.go:78:37: too many errors

Getting error While I'm using go-telegram/bot verion 1.1.4 and go-telegram/ui version 0.2.0!
To solve problem I used 1.0.1 version of go-telegram/bot!
P.S: It is similar to error in issue #1

Same thing
# github.com/go-telegram/ui/keyboard/inline
/home/xxx/go/pkg/mod/github.com/go-telegram/ui@v0.2.0/keyboard/inline/callback.go:31:44: update.CallbackQuery.Message.Chat undefined (type models.MaybeInaccessibleMessage has no field or method Chat)
/home/xxx/go/pkg/mod/github.com/go-telegram/ui@v0.2.0/keyboard/inline/callback.go:32:44: update.CallbackQuery.Message.MessageID undefined (type models.MaybeInaccessibleMessage has no field or method MessageID)
/home/xxx/go/pkg/mod/github.com/go-telegram/ui@v0.2.0/keyboard/inline/callback.go:53:39: cannot use update.CallbackQuery.Message (variable of type models.MaybeInaccessibleMessage) as models.InaccessibleMessage value in argument to kb.handlers[btnNum].Handler

So sad by that ((

Released v0.3.0


MDD/Hesperomys comparison: Cingulata through Diprotodontia

Following #22, #23, #26. This covers a few smaller orders, which happen to include most of the marsupials. There were relatively few disagreements, mostly around spelling.
Cingulata
Straightforward accepted changes:

New splits

Cabassous squamicaudis < C. unicinctus
Dasypus beniensis, D. pastasae < D. kappleri

New mergers

Dasypus hybridus -> D. septemcinctus

Dasyuromorphia
Straightforward accepted changes:

New mergers

Phascolosorex brevicaudatus -> P. dorsalis (another Helgen (2007) suggestion that hasn't received support)
Sminthopsis aitkeni -> S. fuliginosa

New splits

Sminthopsis froggatti, S. stalkeri < S. macroura

Spelling changes:

Dasycercus cristicaudus -> cristicauda (best interpreted as a noun in apposition)

Recently extinct species

Thylacinus cynocephalus

Dasyuridae
Murexia melanura vs. melanurus (-)
The original spelling (in combination with Phascogale) was melanura. It was melanurus when the species was in Murexechinus, but Murexia is feminine, so melanura is correct.
Murexia hageni and M. wilhelmina (+)
I have these as valid, MDD does not.
These were also based on Helgen (2007), like Hipposideros fasensis. I don't think these splits have been accepted so I'm synonymizing them.
I found a Wikipedia article on a related species "Murexia xenochromus": https://en.wikipedia.org/wiki/Murexia_xenochromus, which appears to be a hoax. I'm proposing it for deletion.
Myoictis wavica vs. wavicus (-)
I have wavica, MDD has wavicus.
The genus name comes from Greek ἴκτις iktis, which is feminine. The specific epithet looks based on the type locality Wau, which would make it an adjective.
However, Myoictis melas wavicus was the original name and I don't think anybody has ever used wavica.
AI: Confirm and publish.
Didelphimorphia
Didelphidae
Caluromysiops irrupta vs. irruptus (-)
I have irruptus, MDD has irrupta.
Like Myoictis wavica, this is a case where I think the grammatical evidence is strong, but I am not convinced it's worth disrupting the established nomenclature. (-ops names are always masculine per the Code; irrupta is clearly an adjective.)
AI: Confirm and publish.
Marmosa waterhousei vs. waterhousii (-)
I have waterhousei, MDD has waterhousii, which is the original spelling.
I follow Voss (2022:15), who argues that waterhousei is a justified emendation through prevailing usage.
Ref: Voss, R.S. 2022. An annotated checklist of Recent opossums (Mammalia: Didelphidae). Bulletin of the American Museum of Natural History 455:1-74.
Diprotodontia
Straightforward accepted changes

New mergers

Thylogale lanata -> T. brownii
Trichosurus arnhemensis -> T. vulpecula

New splits

Ailurops furvus < A. ursinus
Strigocuscus sangirensis < S. celebensis
Petauroides armillatus, P. minor < P. volans
Phalanger breviceps < P. orientalis (though I haven't yet seen the source)

Spelling changes

Onychogalea fraenata -> O. frenata
Pseudochirulus schlegeli -> P. schlegelii

Omitted recently extinct species

Dactylopsila kambuayai (though apparently it's not extinct)
Bettongia pusilla

Other changes

Strigocuscus pelengensis -> Phalanger pelengensis

Articles not yet seen:

Kealy, S., Donnellan, S. C., Mitchell, K. J., Herrera, M., Aplin, K., O'Connor, S., & Louys, J. Phylogenetic relationships of the cuscuses (Diprotodontia: Phalangeridae) of island Southeast Asia and Melanesia based on the mitochondrial ND2 gene. Australian Mammalogy, 42(3), 266-276.

Macropodidae
Thylogale browni vs. brownii (-)
I have brownii, MDD has browni.
The brownii spelling is original, but most (though not all) recent authors use browni.
Petauridae
Petaurus biacensis and P. papuanus (-/+)
I have Petaurus papuanus as a species, including P. biacensis; MDD has biacensis as valid and lumps papuanus in P. notatus.
This is a hard case. Cremona et al. (2021) recognized P. notatus and P. ariel as valid for some Australian populations previously assigned to P. breviceps, leaving P. breviceps restricted to a small area of eastern Australia, but ignored the New Guinea populations. I got around that by declaring the oldest name from New Guinea, papuanus, to be a valid species, though nobody has explicitly suggested that; you instead lumped them in the geographically nearest species, P. notatus, even though Malekian et al. (2010) found the New Guinea populations to be distant from P. notatus (their AUS2 clade). Both options are problematic. I'd like to propose an alternative: put the New Guinea material back in P. breviceps until somebody gets around to formally separating them. That way, at least their species name only has to change once.
I don't know however why I lumped P. biacensis into P. papuanus. I'm going to move it back to a species.
Pseudocheiridae
Pseudochirops dahlii vs. Petropseudes (-)
I have Petropseudes as a synonym of Pseudochirops, you have it as a genus.
My source is Meredith et al. (2010), who found Pseudochirops to be paraphyletic with respect to Petropseudes and accordingly merged the two genera.
Ref: Meredith, R.W., Mendoza, M.A., Roberts, K.K., Westerman, M. and Springer, M.S. 2010. A phylogeny and timescale for the evolution of Pseudocheiridae (Marsupialia: Diprotodontia) in Australia and New Guinea. Journal of Mammalian Evolution 17(2):75-99. doi:10.1007/s10914-010-9129-7

Here are my responses by change.
Murexia melanura vs. melanurus (-) – I will follow the Hesperomys spelling.
"Murexia xenochromus" – wow, I hadn’t seen this but that definitely appears to be a hoax of some sort cause I’ve never seen that name (the page is now deleted so I wasn’t able to see it).
Myoictis wavica vs. wavicus (-) – although nobodies made this change, I agree with this change and think we should use the Hesperomys spelling.
Caluromysiops irrupta vs. irruptus (-) – because the name has not been around for 100 years without anyone using the alternate spelling, it should probably be changed. However, we might want to email Bob Voss and Sharon Jansa about it, as they might have some more to say about changing it. I’ll leave it on the MDD for now but add a comment.
Marmosa waterhousei vs. waterhousii (-) – I will make the change on the MDD to follow Hesperomys.
Dactylopsila kambuayai (though apparently it's not extinct) – this is based entirely on the Handbook series, I think Ken Aplin (who recently passed away) is the one with proof that the species is still extant, but I think Stephen Jackson or Kris Helgen would be good people to ask about this further (I think I did ask Kris a while back but can’t remember his response).
Phalanger breviceps < P. orientalis (though I haven't yet seen the source) – Just sent you this.
Thylogale browni vs. brownii (-) – will follow Hesperomys on this.
Petaurus biacensis and P. papuanus (-/+) – This is definitely a difficult one, as I don’t think any of the three proposed options really make me feel comfortable. I chose to include it in P. notatus because I was working on a book for Lynx Edicions at the time, and including it in P. breviceps didn’t make sense biogeographically and P. notatus had a distribution up to Cape York, which was the closes to papuanus. However, after thinking about it for a while, I actually agree with you in recognizing papuanus as a species and giving strict indication of why we chose to do so for now, especially since molecular data shows that there are likely multiple species in New Guinea and that these forms are separate from Australian populations. I will add papuanus as a separate species, but I am retaining P. biacensis, as I can’t find any sources that synonymize the name at the moment.
Pseudochirops dahlii vs. Petropseudes (-) – Honestly, I’m pretty amazed that this hasn’t been followed by most subsequent authors, but it seems like there are multiple publications supporting this lump. I will follow this lump, but this is what Jackson and Groves 2015 say about it: “An assessment by Meredith et al. (2009a: 567) found Pseudochirops to be paraphyletic with respect to Petropseudes, grouping the latter more closely to Pseudochirops cupreus than to Pseudochirops archeri. As a result they suggested subsuming Petropseudes dahlii into Pseudochirops as Pseudochirops (Petropseudes) dahlii (Meredith et al. (2009: 567). We here retain the distinctive genus Petropseudes, but recommend revision of the entire subfamily to determine whether the monophyletic clades require recognition at generic level.”
Meredith RW, Westerman M, Springer MS. A phylogeny of Diprotodontia (Marsupialia) based on sequences for five nuclear genes. Mol Phylogenet Evol. 2009a;51:554–571.| Meredith, R.W., Mendoza, M.A., Roberts, K.K., Westerman, M. and Springer, M.S. 2010. A phylogeny and timescale for the evolution of Pseudocheiridae (Marsupialia: Diprotodontia) in Australia and New Guinea. Journal of Mammalian Evolution 17(2):75-99.


remove automatic recovery from replication failure

also

refactor the code so AgentWatcher handles all the agent status checking including couch replication status
tier0 case doesn't set WQ replication any more.

Don't merge yet need further test.

Hmmm, it seems it does not create the workqueue replications in couchdb 1.6
cmst1@vocms008:/data/srv/wmagent/current $ curl "USER:PASS@localhost:5984/_replicator"
{"db_name":"_replicator","doc_count":2,"doc_del_count":0,"update_seq":3,"purge_seq":0,"compact_running":false,"disk_size":12386,"data_size":2561,"instance_start_time":"1427214954115204","disk_format_version":6,"committed_update_seq":3}

, though looking at the code it looks right.
I've to debug it further ...

Alan, sorry about that there seems to be a bug on the code. I updated the patch and updated the vocms008.


⚠ Bofrost.be has degraded performance

In 13f7afb, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1751 ms

Resolved: Bofrost.be performance has improved in d7d0505.


gio add Icon & LoadableIcon subclassing support

can be useful for serializing your custom icon & sending it over dbus :-) I'm not super sure about the whole load_async & load_finish ones though.

Needs to be re-opened on gtk-rs-core.


Silliman__Create ci.yml

Do not approve this pull request until branch "project structure for testing" has submitted a pull requested and is merged to main


IPv6 address will add a network card suffix

Which Component
eg. Nacos Discovery 2.2.10-RC1
Describe the bug
New function of IPv6 address registry will add a useless network card suffix. For some client, it will cause call downstream service failed.
This is my network information:

The IPv6 address got from registry:

For Spring Cloud Gateway, it can call downstream service by using IPv6 addrsss of [2408:400a:8c:5400:6578:5c42:77b1:bc5d%eth0]:20001.
For OpenFeign & RestTemplate, it called failed.

Expected behavior
We should remove the suffix of %eth0 in IPv6 address.

I solved it and close now.


how to test the AP/APH of my own data and 3d-detection model?

Hi,@open-mmlab team!
Thanks for your great work!
I want to ask if I could test the AP/APH with my own data (pointcloud)and 3d-detection model?
if not,what could i do to get this 2 value?
Looking forward to your reply, it helps me a lot !
Thanks again.

see here


Polkadot Facade Feedback

We are working towards building better APIs to simplify the interacting with "Polkadot Network".
What do we mean here by Polkadot Network? Foremost Polkadot Relay Chain and System Chains (everything DOT related), and then other Parachains.
In a few months (and after gathering feedback via such issues), more details of this project will be shared. To give it a name for now, we are calling it "Polkadot Facade".
The aim of this issue is to learn about the instances where you had to interact with Polkadot Network (as defined above), and you found it difficult. This interaction can be in any form, but to help give you a mental model, I can categorize it as such:

🤓 read: You had/wish to read something from the chain (most likely a pallet's storage / runtime-api), and you found it difficult.
✍ write: You had/wish to compose a transaction to do something, and you found it difficult.

A few notes:

I used the "had/wish" intentionally: I would like to hear both about scenarios that you had to do something, and they were hard, and those that you couldn't even figure out how to do because it was too hard.
You can focus both on single-network interactions, and multi-network (involving XCM) interactions. That being said, we will likely first consider single-network cases.
When it comes to reading, don't limit yourself to what can be read from the state of a certain block, historical queries also count.

Please feel free to reach out to me on Matrix (@kianenigma:parity.io) if need be.

For Multix in particlar, here are the issues that I could think of:

The existence and success of Multix is a proof that the multisig pallet was not conceived with users in mind. This can't and won't change any time soon, but these are the obvious issues:

multisigs can't be discovered from the chain based on an account
the multisig calls waiting for approval aren't stored on chain and require either a hack (like multix see wiki) or a DB, like what most of the other interfaces handling multisigs have

One thing that could change and makes it so that Multix requires an indexer for is that pure proxies can't be discovered solely with on-chain data. Requiring and indexer here too. We know proxies, but we don't know whether a pure proxy was created. You have to look at the chain events.

another issue that you know about, but that I can't avoid talking about: pure proxies and cross-chains don't go hand in hand. First of all, you can't replicate a pure proxy today https://github.com/polkadot-fellows/RFCs/pull/111. Second what Josep told me, if you are the controller of a pure proxy, you can't make an XCM message to let this pure proxy account do anything on another chain. This is a major pain point, the most obvious need for this is abstracting chains for users, and set an identity (on the ppl chain) for a pure proxy on the relay.

I'll answer in new comments here if anything else comes to mind

closing as nothing actionable for us.


404 for<EMAIL_ADDRESS>

Describe the bug
Got 404 Not Found<EMAIL_ADDRESS>when use verdaccio an an npm registry
To Reproduce
Steps to reproduce the behavior:

clone verdaccio (for example)
use verdaccio as an npm registry
exec npm install
see the error 404 Not Found<EMAIL_ADDRESS>
But npm view<EMAIL_ADDRESS>shows package info correctly
Expected behavior
no 404
Screenshots
If applicable, add screenshots to help explain your problem.

Configuration File (cat ~/.config/verdaccio/config.yaml)
Native config file (no changes)
Debugging output
Error from log file:
4481 verbose stack Error: 404 Not Found<EMAIL_ADDRESS>4481 verbose stack     at fetch.then.res (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/fetchers/registry/fetch.js:42:19)
4481 verbose stack     at tryCatcher (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
4481 verbose stack     at Promise._settlePromiseFromHandler (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
4481 verbose stack     at Promise._settlePromise (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
4481 verbose stack     at Promise._settlePromise0 (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
4481 verbose stack     at Promise._settlePromises (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
4481 verbose stack     at Async._drainQueue (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
4481 verbose stack     at Async._drainQueues (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
4481 verbose stack     at Immediate.Async.drainQueues (/usr/local/Cellar/node@8/8.11.3_1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
4481 verbose stack     at runCallback (timers.js:810:20)
4481 verbose stack     at tryOnImmediate (timers.js:768:5)
4481 verbose stack     at processImmediate [as _immediateCallback] (timers.js:745:5)

First try, works.
~/node_experiments/npm_test is 📦 v1.0.1 via ⬢ v9.4.0 on 🐳 v18.03.1-ce
➜ npm install<EMAIL_ADDRESS>--registry http://localhost:4873

npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.

+<EMAIL_ADDRESS>added 1 package from 1 contributor and audited 4 packages in 1.804s
found 0 vulnerabilities

Describe your environment.
Babylon is a old budy around here https://github.com/verdaccio/verdaccio/issues/594

Seems like we need to remove babylon-7.0.0-beta.0-ranges from our verdaccio storage?

@smelukov no because your version is different. Please describe your environment, a lot of factors might cause your issue.

@smelukov Please feel free to open if the issue persists.


Techdocs CLI serve results in a 404 error

Expected Behavior
Running npx @techdocs/cli serve displays the techdocs
Actual Behavior
Running npx @techdocs/cli serve displays a 404 page
Steps to Reproduce

Set up a local mkdocs repo
npx @techdocs/cli serve
The 404 will appear in the opened browser window

Context
This seems to be a regression in 1.0.0. npx<EMAIL_ADDRESS>serve displays the buggy behaviour. npx<EMAIL_ADDRESS>serve works as expected.
The logs for the docker container that is spawned contain a 404 error, snippet below:
INFO     -  Documentation built in 1.95 seconds
INFO     -  [05:30:43] Serving on http://<IP_ADDRESS>:8000/
WARNING  -  [05:30:47] "GET /techdocs/index.html HTTP/1.1" code 404

Hey @realandersn, thanks for looking at this.
Steps to reproduce:
mkdir techdocs-cli-404-reproduction
cd techdocs-cli-404-reproduction
cat > mkdocs.yaml <<EOF
site_name: test-site
nav:
  - Home: index.md
plugins:
  - techdocs-core
EOF
mkdir docs
echo "# Home" > docs/index.md
npx<EMAIL_ADDRESS>serve

Expected: The created page is displayed
Actual: The 404 'mic drop' page is displayed
Running npx<EMAIL_ADDRESS>serve works as expected.

I'm getting the same 404 behavior techdocs-cli serve v1.0.0.
However, all is working fine when I run techdocs-cli serve:mkdocs.

Hmm...  I too am unable to reproduce, even with the detailed/scripted steps from Nik (thanks, BTW!).
What's more odd is that other than a few dependency bumps, v0.8.17 and v1.0.0 of the CLI are basically identical
Wondering if there are any other clues to why it might be working for Anders and I but not y'all.  Are y'all on windows?  What version of docker are you running?

I am getting this on Linux with Docker 20.10.14.  A colleague is also encountering the same issue on macOS (not sure which versions).  I tested this with @Niksko's comment above and am also getting ERROR 404: Error: Page not found.
One odd thing I have is that the error message talks about techdocs.builder not being set to local, maybe that could be the cause?  Here's the full error message + a screenshot:
ERROR 404: Error: Page not found

Note that techdocs.builder is not set to 'local' in your config, which means this Backstage app will not generate docs if they are not found. Make sure the project's docs are generated and published by some external process (e.g. CI/CD pipeline). Or change techdocs.builder to 'local' to generate docs from this Backstage instance.
Looks like someone dropped the mic!
[Go back](http://localhost:3000/docs/default/component/local/)... or please [contact support](https://github.com/backstage/backstage/issues) if you think this is a bug.

And finally, my system details if relevant:
$ uname -a
Linux metaphya 5.17.2-arch3-1 #1 SMP PREEMPT Sun, 10 Apr 2022 11:18:32 +0000 x86_64 GNU/Linux

$ docker version
Client:
 Version:           20.10.14
 API version:       1.41
 Go version:        go1.18
 Git commit:        a224086349
 Built:             Thu Mar 24 08:56:17 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.14
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18
  Git commit:       87a90dc786
  Built:            Thu Mar 24 08:56:03 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.2
  GitCommit:        de8046a5501db9e0e478e1c10cbcfb21af4c6b2d.m
 runc:
  Version:          1.1.1
  GitCommit:
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Wondering if there are any other clues to why it might be working for Anders and I but not y'all. Are y'all on windows? What version of docker are you running?

Nope, running on Mac. We're able to reproduce across a few devs at my org.
$ uname -a
Darwin L4653 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64 i386 MacBookPro16,1 Darwin

$ docker version
Client:
 Cloud integration: v1.0.22
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:46:56 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.5.0 (74594)
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I've submitted a fix above. I'm really puzzled as to why this isn't reproducible for people, the fix is fairly straightforward.
For those who can't reproduce: when you load the http://localhost:3000/docs/default/component/local/ after running serve, what URL does your browser request when it requests the techdocs index.html?
For me:

Version 1.0.0: The browser requests http://localhost:3000/api/techdocs/index.html which returns a 404
Version 0.8.17: The browser requests http://localhost:3000/api/index.html which returns a 200

The bug is that when the embedded-app is resolving the base url for the techdocs API, it used to read the value from config, and it was hardcoded to http://localhost:3000/api. The change I reference in the PR removes this, and so the base url for the techdocs API now resolves to http://localhost:3000/api/techdocs, as it should for a real Backstage installation.
The techdocs-cli when running with the embedded-app (i.e. @techdocs/cli serve) proxies requests to http://localhost:3000/api to the mkdocs container. When it does the proxying, it strips the api portion of the path, but it wasn't stripping the techdocs portion of the path that was added above.

+1 on fixing this (haven't gotten to try @Niksko's fix but hope it works).
folks at my org have found techdocs-cli super unstable. pretty much every update brings some issue that breaks local workflows. would love to see more focus on stability in future techdocs cli releases. (don't mean to be nagging. i realize it's a hard thing to get right and that i'm not proposing any solutions :) )

I have closed #11177 in favor of this issue. I will also re-test using the notes outlined in #11466.

Yes, I've replicated the behavior that @Niksko outlines and has provided a fix for. Waiting for his PR #11051 to be finalized and released in the "nightly" build in order to retest the fix.

@zhammer agreed. We're developing our own tooling to further abstract the TechDocs details away from developers, especially for documentation-only repositories by using containerized tooling with commands that "just work" out-of-the-box across hosting platforms. As a result, we are "pinning" tooling versions to known, working versions, but bugs like this even make that difficult. I just ran into a new issue that is likely a bug, where I can't upgrade MkDocs Material, because of something in the TechDocs MkDocs plug-in 🤷🏼♂

Hey folks, this was resolved by #11467. I can confirm that it's fixed on master. Happy to close this.

Thanks @Niksko . I've confirmed this is working with the nightly build in this repo:
https://github.com/ericis/test-techdocs-cli-serve
Both commands now work properly:

techdocs-cli serve
techdocs-cli serve -v --no-docker

@Niksko I found a fun related bug that produces a 404 when MkDocs "site_url" is configured outlined in #11557. I'm not certain that your code may have caused this regression, since you used a RegEx for pattern matching, but possibly.

FWIW, I saw this same 404 error. Adding a link from our custom-named homepage to  docs/index.md fixed it for me.


Supporting royalties that live alongside the NFT

Problem
Some projects have complex royalties structures that they want enforced in any plattform that sells or transfers that NFT. In order to support this several solutions have included Royalty data into the NFT resources themselves.
Some examples here are:

Versus have Artist Royalty and Minter Royalty stored in the NFT
Flovatar has a 1% Minter royalty stored in the NFT
NeoCollectibles have a Royalty to the Owner of the main Motorcycle NFT on trades of NFTs in its crews.

Work done to support this thus far
In https://github.com/onflow/flip-fest/issues/16 this was discussed but it was taken out of the final document because more stakeholders wanted a say.
bjartek, dete, rhea had a meeting about this because bjartek (as a proposed) and rhea (as a representative of dapper) had a disagreement about how it should work. In this meetin the following struct was agreed upon
	/// A struct interface for Royalty agreed upon by @dete, @rheaplex, @bjartek
	pub struct interface Royalty {

		/// if nil cannot pay this type
		/// if not nill withdraw that from main vault and put it into distributeRoyalty
		pub fun calculateRoyalty(type:Type, amount:UFix64) : UFix64?

		/// call this with a vault containing the amount given in calculate royalty and it will be distributed accordingly
		pub fun distributeRoyalty(vault: @FungibleToken.Vault)

		/// generate a string that represents all the royalties this NFT has for display purposes
		pub fun displayRoyalty() : String?

	}

The main proposal here came from dete and some subleries of it was discussed and we agreed upon what is stated above.
Here is an implementaion of how that can work for Versus art.
https://github.com/findonflow/find/blob/testing/contracts/Art.cdc#L323

I have found an issue I do not like with the above model. And that is that it is impossible to emit a good Event when royalty is paid out since the context of the item you want to pay royalty is not sent into the distributeRoyalty method. I guess you could work around this in various wayt but I still think it is tedious. Beeing able to send in some more fields to distributeRoyalty would be preferrable so that we can have a good Royalty event that.
In fact that is one point we did not discuss in the meeting where the above struct was agreed upon. Emitting a good event that can be used across different solutions.

For the record this is the code that I use now to resolve the above.
		pub let royalty: { String : RoyaltyItem}
		init(_ royalty: {String : RoyaltyItem}) {
			self.royalty=royalty
		}

		pub fun calculateRoyalty(type:Type, amount:UFix64) : UFix64? {
			var sum:UFix64=0.0
			for key in self.royalty.keys {
				let item= self.royalty[key]!
				sum=sum+amount*item.cut
			}
			return sum
		}

		pub fun distributeRoyalty(vault: @FungibleToken.Vault) {
			let totalAmount=vault.balance
			var sumCuts:UFix64=0.0
			for key in self.royalty.keys {
				let item= self.royalty[key]!
				sumCuts=sumCuts+item.cut
			}

			let totalKeys=self.royalty.keys.length
			var currentKey=1
			var lastReceiver: Capability<&{FungibleToken.Receiver}>?=nil
			var lastName:String=""
			for key in self.royalty.keys {
				let item= self.royalty[key]!
				let relativeCut=item.cut / sumCuts

				if currentKey!=totalKeys {
					let amount=totalAmount*relativeCut
					emit RoyaltyPaid(name: key, amount: amount, type: vault.getType().identifier)
					item.receiver.borrow()!.deposit(from: <-  vault.withdraw(amount: amount))
				} else {
					//we cannot calculate the last cut as it will have rounding errors
					lastReceiver=item.receiver
					lastName=key
				}
				currentKey=currentKey+1
			}
			if let r=lastReceiver {
				emit RoyaltyPaid(name: lastName, amount: vault.balance, type: vault.getType().identifier)
				r.borrow()!.deposit(from: <-  vault)
			}else {
				destroy vault
			}
		}

		pub fun displayRoyalty() : String?  {
			var text=""
			for key in self.royalty.keys {
				let item= self.royalty[key]!
				text.concat(key).concat(" ").concat((item.cut * 100.0).toString()).concat("%\n")
			}
			return text
		}
	}

I have found an issue I do not like with the above model. And that is that it is impossible to emit a good Event when royalty is paid out since the context of the item you want to pay royalty is not sent into the distributeRoyalty method. I guess you could work around this in various wayt but I still think it is tedious. Beeing able to send in some more fields to distributeRoyalty would be preferrable so that we can have a good Royalty event that.
In fact that is one point we did not discuss in the meeting where the above struct was agreed upon. Emitting a good event that can be used across different solutions.

Hey @bjartek could you please fill me in about the event data that you are envisioning so I could architect the same stuff in my head. AFAIK the required data needed is Amt get distributed as royalty, beneficiary, description of some type to depict the reason or any data that we want to fill in, Maybe some data related to the NFT_ID as well anything else that you thought so ?

In my eyes a good royalty event should contain the following fields

name: what is the name of this royalty, is it "minter", "originalArist", "marketplace". This is purely for informational purposes
amount: The amount of royalty paid
type: the type of FT.Vault that was paid
receiver: who received the royalty
payer: who triggered the payment of this royalty, the purchaser

Fields I am not so sure about are:

percentage: the percentage of tx that was paid
totalAmount: the total amount of the tx

You point on adding information about the UUID of the object royalty was paid for is also something that I think would be very nice.

Awesome! Thanks for the input

Name -> It can be covered under the description.  ✅
Amt ✅
receiver -> ✅
type of vault -> ✅
payer -> ✅
UUID -> ✅

I don't think percentage is necessary as that can be easily calculated by other metadata offchain and neither the totalAmt as the all event summation would give total amount so again can be re-created offchain.
I think every piece of data can be easily retrieved without passing extra data in the purchase function of the storefront/marketplace contract if it is carefully designed.

@satyamakgec Can you post your proposal here? Like others have said elsewhere, the distribution should probably not happen in the royalty struct. The royalty struct should probably only just return the information about the royalties and the individual marketplaces should be responsible for distributing them.

Yeah sure @joshuahannan , Below is the representation what I think will be sufficient to facilitate the royalty information within the NFTs.
// Struct that keeps the data related to the royalty.
pub struct RoyaltyDetails {

     // Capability of the receiver.
     receiverCapability,
      // Percentage of salePrice in basis points
     basisPoints,
     // Could be optional, It will be simple string to tells about what for the royalty is.
     description
}

// Struct used as the return type for the `royaltyInfo` function.
pub struct RoyaltyInfo {

    // Capability of the receiver.
   receiverCapability,
   // It is the amount that get calculated on the basis of the `RoyaltyDetails.basisPoints` & `salePrice`
   saleCut,
  // Optional description
  description

}

// Interface that needs to implement by the NFTs to support the Royalty info, It will be a voluntary implementation as there will be many cases where marketplace don't want to support it.
// This interfaces doesn't care about how payment of the royalty would happen as it will be cumbersome to handle within the standard and make the standard rigid. The idea here is to make the standard flexible as much as possible so it can support many innovations.
pub struct interface Royalty {

  // Below function will calculate the royalty cut on the basis
  pub fun royaltyInfo(nft_id: UInt64, salePrice: UFix64): [RoyaltyInfo]
}

The idea it to keep it flexible so implementer of the royaltyInfo() could return royalties in different variants, Like decaying royalties, stepped royalties or many other techniques implementer can implement under the royaltyInfo function. Whilst marketplace only needs three values capability which is going to receive the funds, amount of cut needs to transfer & and optional description.
Happy to receive feedback.

In order to calculate the proper royaltyInfo in your above implementation the royaltyInfo has to include the type of Vault you would want the royalty to be paid as. If it does not it is impossible to return the correct receiverCapability in the RoyaltyInfo. (if you do not use an abstraction around receiver that support multiple wallets)
So given that you have an item that is sold for 10.0 and you have an artistCut of 2.5% and a originalMinter cut of 1% the royalty info returned here would be
[ {capToArtist, 0.25, "artist"}, {capToMinter, 0.1, "minter"}]
Is that the correct way to interepet your suggestion?

This is nice but lacking much tbh vs original proposal.
It is important to resource to know royalty distributed, so you can also implement royalties on first N sales, royalties with decreasing percentage by some algorithm on sales etc.

It is important to resource to know royalty distributed, so you can also implement royalties on first N sales, royalties with decreasing percentage by some algorithm on sales etc.

Also for example, if resource cannot distribute royalty, it can keep royalty inside of resource, and can try to distribute on next transaction etc.

It can be a requirement but adding distribution of the royalty within the resource would lead to complexity within the standard itself. We can apply the different algorithms on the basis of timestamp but it could be hard to do so with the no. of sales as we never know when the distribution is going to happen.
I am open to suggestions to find a way to support the No. of sales

@satyamakgec I was thinking a bit in the context of other contracts like NFTStorefront for example.
If we can somehow manage a  distributeRoyalty function, other contracts can use this instead of managing to split royalties themselves,  then for example NFTStoreFront can get rid of cuts somehow mostly or totally.
btw when I say distributeRoyalty, it can also stay as a public function in another contract (let's say RoyaltyHelper), doesn't have to be implemented inside NFT.
in RoyaltyHelper Contract:
fun  distributeRoyalty(royalties: [RoyaltyInfo] , vault: @FungibleToken.Vault)
in RoyaltyMetadata can have some default implementation like:
pub struct interface Royalty {
  // Below function will calculate the royalty cut on the basis
  pub fun royaltyInfo(salePrice: UFix64): [RoyaltyInfo]
  fun  distributeRoyalty(salePrice: UFix64, vault: @FungibleToken.Vault) {
    RoyaltyHelper.distributeRoyalty(royalties: self.royaltyInfo(salePrice: salePrice), vault:vault)
  }
}

so any user somehow can:

call royaltyInfo(salePrice: X)
calculate totally royalty to be paid
withdraw royalties from purchase Vault
call distributeRoyalty
rest of the vault sent to seller

But my main point is if we suggesting RoyaltyInfo with net prices ( calculated with sale price ) , distribution part is the easy part, also at least we can guarantee that if some Market is using let's say NFTStoreFront contract ( if NFTStoreFront implements this workflow), they are respecting the royalties.

I don't think so that NFTStorefront can get rid of cuts totally as it is going to facilitate the payment of the listing and other operational stuff as well.
For me keeping the payment and the standard it self aside is more cleaner approach as I don't need to write the logic of payments when I am going to design the NFTs and it can lead some inconveniences during the sale of NFT as at two places contains the distribution logic as well, One is distributing the saleCut and other one specifically paying the royalties.
Another thing I have in mind that if we are going to keep the distribution royalty method in the standard then there could be malicious implementation that can affect the purchase of the NFT it self, There are a lot of unknowns if we keep the distribution method under the standard.
But I am also not denying the fact that it will be much more convenient to design the sale algorithm if we have the distribution under the standard umbrella, Maybe one thing more we can do is add a hook/callback in the NFT storefront contract to update the no. of sale in the NFT contract although it is not a cleanliest approach either but it will work and here we have to trust only one contract i.e NFT storefront.

This is a much more complicated view discussion than the Display one! So many different variables! 😆
It might make more sense to use an address instead of a capability to be generic, so we don't have to worry about specifying the token type in the royalty specification. It could just apply to all token types. Unless maybe there is a specific reason someone would want to restrict who gets paid royalties depending on what token is being used for the payment? I'm not sure.
I am a fan of Satyam's suggestion. I think is is fairly clean. I don't know how much we should be able to enforce about timestamp or first N payments in the royalty standard, but I am not familiar with other royalty standards. To me it seems like that would still work under the hood for the NFTs and can just be in a manual implementation.
And I am fine with keeping the distribution separate from the standard. I can see it being in a separate contract or up to the marketplace developer, but not in the standard. Like others have suggested, some sort of callback in the standard to mark when a sale has happened could be useful, but not actually distributing the royalties.
@psiemens What do you think about this discussion? Is there anything from your suggestions that you'd like to add?

I am not in favor of using an address. It forces the implementation of the wallet to be the one that is behind a specific path and it does not even ensure that the user has that path linked.  There are still accounts that have not FUSD linked/stored.
Lets say somebody wants to use a pooling/split wallet behind the royal for a given item. That should be possible and a capability ensures that is possible.
.find has a profile that is a FT.Receiver and can distribute any kinds of funds. You just register a new wallet in the profile and it will distribute to the first wallet in its configuration that matches the vault you send in.

Correct @satyamakgec.
This is the deposit method https://github.com/findonflow/find/blob/main/contracts/Profile.cdc#L386
You can also call this in find to get a better event then the current once with this tx:
https://github.com/findonflow/find/blob/main/transactions/sendFlowWithTagAndMessage.cdc#L80

Thanks @bjartek this is helpful, We could support something like that but I am not sure whether we need to create a generic contract to support that feature so it could use industry wide as well or whether we can directly use the solution you suggested.
I mean we need to standardise that solution as well without doing it we may lead to discrepancies.

@bjartek's solution is great, I think we need a generic receiver interface for sure.
Somehow I am torn on the panic if Vault type not exists vs storing the received Vault ( and later automatically having this Vault type), though as we have storage fees currently latter option is not possible. ( DoS risk )
When I was thinking that recently I proposed to get rid of Storage Fees ( https://github.com/onflow/flow/issues/791 )

Good point @bluesign. I would have no problem switching to that on for .find if it became available. It is not even that hard to implement TBH.

Wondering if you considered to use some sort of proxy contract for storing various FT vaults.

Rhea wrote up a "token switchboard" proxy contract that does this (forked to my GH): https://github.com/psiemens/flow-ft-switchboard/blob/main/cadence/contracts/FungibleTokenSwitchboard.cdc
@bjartek It's very similar to what you have in Profile
We were also thinking that the royalty implementation should just deposit to the proxy.

This implementation works in effect exactly like we have in the find profile.
It still lacks @bluesign nice concept of escrowing ft that you do not have a receiver for. So in deposit if you do not find a receiver then escrow funds and emit a good event.
I would not want my tx to fail because one royalty holder does not have a new ft type linked.

Here is my thoughts on royalties. Let's say A is a third-party marketplace and B is NFT project. And in the end we are using storefront contract and in the end we just need sale cuts with amounts.
A wants to sell B NFT. So A asks NFT what are your royalties? B tells that there is 5% creator royalty, 5% project royalty and 1% minter royalty. 11% in total. Also, let's say that A has capped royalties at 10%.
So there options:

A cannot list B NFTs for sale
A can raise the cap to the 11%, but again, NFT can ask for 30% royalties or 100% in extreme cases
B can adjust their royalties to fit into those 10% (either proportionally reducing each share or doing it at someone's expense)
if B royalties is below 10%, then there is no issue and we continue

After royalties are clear, those can be easily transformed into sale cuts and put into listing.
As for events, the issue is that storefront does not emit any specific royalty events. It is very generic and you need off-chain tracker to use it properly, which is huge con. Not sure what we can do here with events. Receiver could emit event, but as @bjartek  mentioned it will just have the amount and will be out of context. It would need at least listing id, better NFT type and id, royalty percent and all that. We could add royalties field in storefront and use that to emit corresponding event on purchase, but it is not possible to add new fields to resources (right?).

I think here as @bjartek mentioned, escrowing the FT is important feature, in the future some new stable FT will come and marketplaces will start to support, you cannot expect every royalty holder to support instantly.

Personally I did not know that bay had a 10% royalty cap. If they do I think the only sane option is for them to not allow listing if you have royalty above that. It is the only sane option. Handling scenarios like @vleushin have specified above is just too complicated imho. If a NFT contract want more then 10% then they have to live without bay support.

I generally agree with this, but I also don't think it affects this implementation. It's a product preference. I don't think this standard should enforce any royalty caps -- I think it's up to the sale agent (e.g. a marketplace) to enforce their preferred restrictions.

It sounds like these are the features we'd like out of the royalty view:

Multiple royalties and recipients per NFT
Compatibility with the NFT Storefront contract
NFT resource can detect when a royalty is paid
An event is emitted when the royalty is paid

I'm treating the token receiver + escrow problem as a separate issue solved by another contract.
@bluesign @vleushin I see the value in having a single function that distributes the royalties and emits an event. However, I think what we actually want is an event/function that fires not just when royalties are paid, but whenever the NFT is sold.
The question at the crux of this conversation seems to be: should the royalty view be responsible for distributing royalties, or should it just define them? If it doesn't distribute them then we have less control over when/if an event is emitted.
For the purpose of exploring all options, I think we can expand the scope of this conversation to include potential changes to the NFT Storefront contract to better support the features above.

We could add royalties field in storefront and use that to emit corresponding event on purchase, but it is not possible to add new fields to resources (right?).

@vleushin It's not possible, but I think it's OK to consider breaking changes if it helps us narrow down on the ideal solution.

From my perspective the most imporatnt aspect to solve in the spec itself at this point is your two first points. The settlement process you describe for point 3-4 would also be nice, but Personally I would prefer if we could approve the building blocks needed in a Royalty view first and then agree on settlment after.
However here are some thoughts on settlement:
Having a setlement routine that allow transfering one NFT from a given user to another in exchange for some funds that will honor the Royalty spec will be a nice addition here. However while I totally agree that the NFT Storefront contract should be involved, not all transactions that sell NFTs will involve that contract.
Something that I also think is imporatant in this discussion is that in adition to fetching Royalty from the item beeing sold the solution that trigger the settlement could also send in some Royalty that it wants for this transaction.
If an item is sold at Rarible or at Blocto Bay they would want their part of the cut if the transaction was initiated on their end one would imagine. And this is not something that can be stored in the NFT itself.
So am I correct in assuming that the state one such settlement method would need is:

the nft resource you want to transfer
the vault that holds the funds
an aditional set of cuts from the caller of the settlement
the Capability to a collection to deposit the nft too

If that is the case how do you then get the owner of the NFT, does that also has to be sent in?
What I would rather not see in this solution:

sending in a capability to an NFT Provider. I know the storefront uses that pattern but many other solutions that exist today does not.

Splitting Royalty definition from the settlement seems appropriate for the MetadataView
Also perhaps there should be a clear distinction between NFT Royalty and platform Royalty.....
ie. marketplace is responsible for emitting event for their cut and the NFT settlement layer method emits only the baked in royalties stored in the NFT

FYI - There are some improvements we are planning to do in the storefront contract (Not set in stone yet). We can another one to emit an event when the royalty get paid, But it is hard to distinguish right now from other sales cut so we have a plan to support that change in the storefront contract. So if the Storefront contract get used as the marketplace then the end user would get an event of royalty paid.
Something like this RoyatlyPaid(royalty: UFix64, receiver: Address / Proxy contract (separate discussion), description: String, nft_id: UInt64)  --- It is a rough structure it will get improved when the actual change get applied.
For what @psiemens mentioned

Multiple royalties and recipients per NFT. --> Would supported by the Royalty View
Compatibility with the NFT Storefront contract. ---> This is planned change in the storefront contract once Royalty view get finalized.
NFT resource can detect when a royalty is paid.  ---> It is difficult to do as it would need some changes in the NFT contract it self where storefront contract do some callback to the NFT resource to tell the royalty get paid.
An event is emitted when the royalty is paid. ----> Planned change in the NFT Storefront contract.

I agree with @bjartek & @bluesign here that supporting proxy contract with the escrow functionality make sense instead of direct using the address but I think it is out of scope for this discussion, We can have another conversation about that.
Here is the reference of the Royalty view https://github.com/onflow/flow-nft/blob/wip-royalties/contracts/RoyaltyViews.cdc
Happy to receive the feedback.

@satyamakgec I have expressed my view on this further up in this thread several times but I have to ask, why are you using an Address here and not a Capability to a FT.Receiver. Many solutions already use this pattern today.
If you only use an Address you have no way of knowing what vault they have chosen to be used for this royalty. There are already NFTs that are minted today on mainnet that have this logic in them.
An capability to a FT.Receiver also has the ability to get the address of that if for some reason the current Capability does not check.
My suggestion is quite simple and it is
      pub struct Royalties {
		pub let royalties: [Royalty]

		pub init(royalties: [Royalty]){
			self.royalties=royalties
		}
	}

	pub struct Royalty{
		pub let wallet:Capability<&{FungibleToken.Receiver}>
		pub let cut: UFix64
		pub let description:String

		init(wallet:Capability<&{FungibleToken.Receiver}>, cut: UFix64, description:String ){
			self.wallet=wallet
			self.cut=cut
			self.description=description

		}
	}

This may be repeated, but if a marketplace supports royalty payments, most likely it's a single payment to a single address. I don't think they can support distribution to multiple parties--that would need logic.

Are you talking about royalties for the marketplace that are exclusive to those present in the NFT? If so I totally agree that most likely this is a single cut.

Splits will be handled by the NFT or receiving agency. The marketplaces need a single function: they call with an NFT ID and a sale price; the NFT returns the total amount of the royalty due and the payment address. Maybe there's an identifier to let the NFT determine an adjusted rate for a given marketplace, e.g. for negotiated rates or caps, etc.

In all of the flow docs we are encouraged to use capabilities for permissions and communication. And now we want to go back to using addresses? I do not get why we want that. If you need to support multiple FT types for your

This much would be more or less compatible with the EIP-2981. I think this is what OpenSea would be looking for, and I think Rarible, too--they take 2.5% and then "the royalty rate gets delivered to the designated address upon successful sale – all within one single transaction."
Requests for how the NFT splits the royalties would be a separate thing. This would return the array of cuts. The royalties defined in an NFT would serve as the default values. These would determine the total inbound payment due from markets, and also the outbound payments to parties. "Adjustments" could be applied to the defaults to compute differential rates based on number of sales, negotiated rates, etc. NFT should be able to report what adjustment structure was applied on a sale, if any.
The NFT also has to report whether it supports a given standard (boolean). Therefore it might be better to limit the base standard to the single function needed for the marketplaces, or a small set. Other metadata could go in a second standard.
One of my general questions is about currency. The total royalty will be paid in the currency of the sale. On Rarible today, you can only pay for TopShots in FLOW, so I guess that will be the near term solution. The NFT itself can accept FLOW, but how do we handle royalties paid in ETH, etc.?

Oh my i managed to close this by accident.

Please have a look at this, Revised standard with capability support.
https://github.com/onflow/flow-nft/blob/wip-royalties/contracts/RoyaltyViews.cdc
Happy to receive the feedback.

@satyamakgec
I am only hesitant on this:
https://github.com/onflow/flow-nft/blob/226d5b8a7267fb6b08387db0a631317cfdaa112b/contracts/RoyaltyViews.cdc#L50
It looks like good idea at first, but failing on construct can be little problematic in the future. ( You cannot read royalty, if one of the participants somehow messes up with capability )
I think marketplaces should do the check when sending the royalties.

That is actually a good point @bluesign also, having the capability even though it does not check is usefull because it also has an address associated with it. So you could emit an event or even escrow the funds if a marketplace has that feature.

Also does access(contract) allow read access?
https://github.com/onflow/flow-nft/blob/226d5b8a7267fb6b08387db0a631317cfdaa112b/contracts/RoyaltyViews.cdc#L62

I agree about removing the recepient.check(). That is a good catch.
And yes, royalties should be access(self) and there should be a getter function for it
pub fun getRoyalties(): [Royalty] {
    return self.royalties
}

With the upcomming mutability change to arrays that are pub let, does it really make a difference if this  is pub let vs access(self) and an accessor?

Not really. That is just what I default to now

I think it is coming soon. https://github.com/onflow/cadence/pull/1267

@satyamakgec
I am only hesitant on this:
https://github.com/onflow/flow-nft/blob/226d5b8a7267fb6b08387db0a631317cfdaa112b/contracts/RoyaltyViews.cdc#L50
It looks like good idea at first, but failing on construct can be little problematic in the future. ( You cannot read royalty, if one of the participants somehow messes up with capability ) This will be called on every request on to generate Royalty Struct.
If one artist gets pissed and removes capability ( or hacked or any other reason ) not only them, but also everyone loses royalty.
I think marketplaces should do the check when sending the royalties.
PS: of course we can argue NFT contract can check too, but as marketplace will check anyway when sending ( like StoreFront does now ) it complicates unnecessary to create the royalty view.

In my opinion I don't think it will be problematic, On the other hand it will be good to have an early check as to remove the bad actors upfront instead of handling them afterwards or relying on some other contract to handle the similar case. It is more like if the passenger have the valid passport then only it can fly otherwise the passenger are not allowed to fly, Similarly even if the artist is malicious or whatnot it would get removed from receiving the royalty by the setter of the royalty until unless it provides the valid capability.
So I don't see a big issue here or may be I misunderstood what you are trying to say here.
Although I agree on the access modifier that I changed as suggested.

@satyamakgec The problem is that whenever someone queries an NFTs royalty view, that NFT has to construct a new copy of Royalties. If any of the royalty recipients revoke their capability, it will make it impossible for any of the other recipients to receive the royalties since the pre-condition will fail, which can't happen. I agree with bluesign that checking the capability should be the responsibility of the marketplace.
Also, looking at the naming, it might make sense to change the naming of the royalties field to cutInfos or something like that since Royalties.royalties is a bit awkward. Anyone have any ideas?

is more like if the passenger have the valid passport then only it can fly otherwise the passenger are not allowed to fly,

In your case you are grounding plane for one passenger.
this structs are generated each time metadata is queried ( they are not designed to be create once than used ) more like create each time from NFT properties. ( think as views to properties )
So lets say, capability can’t check, it causes all metadata query to fail. (Script or transaction to panic)

Another thing I think we should do when we release new views is to create a implementors guide for them. Because using them properly is important I think.
One of the items we need to handle in this specific case is what to do when resoling royalties if a royalty receiver cap does not check.  There are several options that are possible and I think it is worth noting down some of them in a document.
Options in my eyes:

skip the item and emit an event that says why royalty was not paid
send the funds to another wallet for a marketplace and emit an event.

I would not recommend outright skipping the item without emitting an event.
Another aspect I think it important. is that the source of truth for the royalties should be fetched from the NFT when it is sold, not when it is listed. Contracts are creative with royalty and storing this information in some intermediary outside of the NFT is not something I think we should recommend.
Concrete example:
In the neo contracts one of the royalties is to the Founder of the team. If that hanges the founder royalty will change and that should be reflected if the item was listed before the change.

Also, looking at the naming, it might make sense to change the naming of the royalties field to cutInfos or something like that since Royalties.royalties is a bit awkward. Anyone have any ideas?

cuts or items or cutInfos work. I agree that the double Royalties is awkward.

Would there be any use in the Royalty having an identifier, so adjustments could target specific cuts?  I think the ability to adjust royalty structures based on negotiated rates or other factors will be important.  The Description could serve that purpose, but I'm not sure it was intended for that.

In my eyes the description is for just that @hier01.

Cool, sounds good @bjartek.  I'm good with 'cutInfos' or even just 'cuts'.  Can I get a pointer to the switchboard thing?  Is that a FLIP?

@satyamakgec @psiemens now that the Royalty view has been merged, can you summarise here the status of this issue and if you consider it closed for now?

@louisguitton Yes, the royalty view is complete, so I'll close this issue. There is documentation in the README, and the changes have been deployed to testnet and mainnet. Not many projects and marketplaces have integrated it yet, but it is definitely ready to start integrating.


[[TEST]] Add tests for bad unicode

Previously uncovered territory, improves test coverage metrics.
Test results for bad unicode in a string previously churns out tons of warnings that are hard to follow, so added a more clear warning in that case.

Coverage increased (+0.11%) to 94.86% when pulling 71f8e0f2f0ba6b3c9e4b892ddb8ee22ee9a23c66 on leebyron:unicodetest into 083ca4b58d63dd3d01e2ff72d3ec5070a7f89671 on jshint:master.


Exception does not show anything in logs ( try/finally)-IdentityServerAuthenticationHandler

Exception does not show anything in logs ( try/finally)-IdentityServerAuthenticationHandler
After some hourse digging why something didn't work properly in localhost (it ended up been a missconfiguration in my ids).
I took the sourcecode and saw that there's a try/finally block without a catch (in case something happen just log it).

I've a commit I wish to send you as a PR:

May I have permissions to create a remote branch and send you a PR ?
Regards,

yes please.

yes please.

I still cannot publish my remote branch in order to send you a PR :(

May you please give permissions to my account so that I can publish my remote branch?
Regards,
Lisber

You don't need any permissions to do a PR.


[deliver] add support for App Store Connect API Key

Motivation and Context
Enable App Store Connect API Key auth with deliver (no Apple ID)
Description

Added api_key and api_key_path options to deliver
Used different versions of endpoints that are compatible with both the Apple ID and Token session

Examples
1. New action
lane :release do
  api_key = app_store_connect_api_key(
    key_id: "D383SF739",
    issuer_id: "6053b7fe-68a8-4acb-89be-165aa6465141",
    key_filepath: "./D383SF739.p8",
    duration: 1200, # optional
    in_house: false, # optional but may be required if using match/sigh
  )

  deliver( api_key: api_key )
end

2. New file format
{
  "key_id": "D383SF739",
  "issuer_id": "6053b7fe-68a8-4acb-89be-165aa6465141",
  "key": "-----BEGIN PRIVATE KEY-----\nMIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHknlhdlYdLu\n-----END PRIVATE KEY-----",
  “duration”: 1200, # optional
  “in_house”: false, # optional but may be required if using match/sigh
}

lane :release do
  deliver( api_key_path: "fastlane/me.json" )
end

Testing Steps
Update Gemfile and run bundle install, bundle update fastlane, or bundle update
gem "fastlane", :git => "https://github.com/fastlane/fastlane.git", :branch => "joshdholtz-deliver-app-store-connect-api-key"

@joshdholtz since this was merged into another PR, will this PR be included in the release notes (assuming the release notes are generated automatically)? If not, it probably should hehe
And/or maybe update the PR description of https://github.com/fastlane/fastlane/pull/17235 ? 😇
(Took me awhile to realize that this PR wasn't merged to master, so I was in master looking for the new code and couldn't find it for the world 😆 )

Yup yup, I'll be manually adding it to the release notes when I make it (since it won't appear) 😊
Thanks for asking about it though!


Confusion about the Mahimahi traces

Hi, hongzi,
As the Readme stated, the trace format should be [time_stamp (sec), throughput (Mbit/sec)].  But,

I cannot well understand why there is only one entry in every line (cooked_traces). It seems the throughput for one round-trip is 1500-byte packet.
why the traces for train and test have two entries for every line?

I would like to emulate the real-world experiment. Could you please help me clear these question? Thanks in advance.

Thanks for your question.

The trace you saw (time & bandwidth) in README is for simulation. The single line trace you found next in cooked_trace is for mahimahi emulator. The format of that trace is kind of like "pacing". It indicates the time interval between sending out next packet, as stated in https://github.com/hongzimao/pensieve/blob/master/traces/README.md:

Each line gives a timestamp in milliseconds (from the beginning of the
trace) and represents an opportunity for one 1500-byte packet to be
drained from the bottleneck queue and cross the link. If more than one
MTU-sized packet can be transmitted in a particular millisecond, the
same timestamp is repeated on multiple lines.

The "train" and "test" you mentioned are in simulator, where we use the time&bandwidth format of the trace. The real test, however, is with the Mahimahi emulation and a real video player in https://github.com/hongzimao/pensieve/tree/master/run_exp (see the README there).

Hi, hongzi,
Conversely, how do I create a format [time_stamp (sec), throughput (Mbit/sec)] for simulation using the Mahimahi format?
Could you please help me clear these question? Thanks in advance.


Use of Observation.component

A piece of text should be added to https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Zib_2020_specific_considerations to justify the mapping of Measurement zib concepts to Observation.component of to other elements. Based on my experience with BloodPressure, I've tried to compose a paragraph:

Measurement zibs that are mapped on the FHIR Observation resource often include concepts that contain ancillary data and that are not directly results of the observation or measurement. If it is not possible to map these concepts to an equivalent element or to a core extension of Observation, these concept may be mapped to Observation.component, following a remark in the specification ("or may provide qualifying information to Observation.code") and discussion on Zulip that the use of component for qualifiers is appropriate and preferred above (custom) extensions.

I'm not sure if this is a zib specific issue actually.

Even zitten schaven:

Functional models for measurements will usually be mapped onto the FHIR Observation resource. The type of measurement is conveyed using Observation.code and the result of the measurement is conveyed using Observation.value[x], or Observation.component.value[x] if the measurement consists of multiple components.

However, sometimes the functional model requires that the type of measurement needs to be further specified using a qualifier. For this purpose, the Observation.method and Observaton.bodySite elements can be used. If it is not possible to map these concepts to these elements or to a core extension of Observation, they may be mapped to Observation.component, according to a remark in the specification ("or may provide qualifying information to Observation.code") and a discussion on Zulip, which concludes that the use of component for qualifiers is appropriate and preferred above (custom) extensions.

Voorgestelde tekst ziet er goed uit. Ik zou alleen de link naar FHIR alvast vastzetten op r4: https://www.hl7.org/fhir/r4/observation.html#gr-comp

Dan zou ik willen voorstellen om sectie 11 in de profiling guidelines een beetje om te gooien in:

Special considerations
11.1 Use of FHIR resources
11.1.1 Measurement qualifiers in Observation.component
11.1.2 FHIR Vital Signs compatibility
11.2 Zib 2020 specific considerations
[...]

Hi @mvdzel , this issue is more about the definition than the result of the measurement. For zib BodyWeight the state of clothing is not something that you measure, it's something that you need to know about the measurement. There seems to be a consensus that this can also be captured using Observation.component.

@pieter-edelman-nictiz That is exactly what I mean by "supporting" values, that go in an existing element (like bodySite) or Observation.components, but you have to use the right codes there (#2).
And by "main" value I mean the thing that is measured and that go into Observation.value.
I think we agree?!

(Re: composing component values in value[x]) Using multiple components and leaving value[x] empty is agreed to be a valid solution to this (http://hl7.org/fhir/R4/observation.html#gr-comp). If we approach the problem from a perspective "how could we highlight which component is/are the 'main' values", then maybe we are onto something, but a) duplicating data is not really a solution in my opinion (if the 'main' data itself is not exclusively available in extensions) and b) how big of a problem is this when there are IGs and models to guide you on interpreting a profile.
(Re: mappings) @mvdzel did you mean to link to http://hl7.org/fhir/observation-mappings.html#sct-concept ? This would be an interesting check I guess. Could help to determine if a zib concept is a fit or not (or to check afterwards). This discussion started from a point of view "can we map concepts to components that are not really "component observations"?. I don't know if it helps us answering this question. And then there are situations where (for example) HL7 Vital Signs maps a concept to component when there is a core element (or core extension) available (see also #62).

So ... I think it's clear then? The main value goes into Observation.value[x], and any supporting measurement or qualifier can go in Observation.component, properly coded. When there isn't a single main value, all value go into Observation.component.

The main value goes into Observation.value[x], and any supporting measurement or qualifier can go in Observation.component, properly coded. When there isn't a single main value, all value go into Observation.component.

Yes, I think this is it.

Still need to add this to the profiling guidelines, so I'm reopening the issue.

Added this to the profiling guidelines.


WalletConnectModal milestone v1

WalletConnectModal Swift Milestone 1
Mobile native version of WalletConnectModal available in Swift SDK
SDK
- [x] Show QR Code
- [x] Customizable cloud PROJECT_ID
- [x] Connect with Wallet
- [x] Support Navigation Component via SwiftUI
- [x] Support Navigation Component via UIKit
- [ ] https://github.com/WalletConnect/WalletConnectSwiftV2/issues/903
- [ ] https://github.com/WalletConnect/WalletConnectSwiftV2/issues/833
- [ ] https://github.com/WalletConnect/WalletConnectSwiftV2/issues/834
- [ ] https://github.com/WalletConnect/WalletConnectSwiftV2/issues/871

Web3Modal

Review Web3Modal Native: project brief

IOS 14，WalletConnectModalSheetController dismiss， leaving a layer of gray view


Allow access modifier indentation relative to start of line

Hello!
I can't fix this, sorry. But I found test:
it 'registers an offense for misaligned private in module ' \
   'defined with Module.new' do
  inspect_source(<<-RUBY.strip_indent)
    Test = Module.new do

    private

      def test; end
    end
  RUBY
  expect(cop.offenses.size).to eq(1)
  expect(cop.messages)
    .to eq(['Indent access modifiers like `private`.'])
end

And I didn't found test for no offenses in this case.
So, I wrote it and it fails.

Expected behavior
Successful test:
it 'accepts aligned private in module defined with Module.new' do
  expect_no_offenses(<<-RUBY.strip_indent)
    Test = Module.new do

      private

      def test; end
    end
  RUBY
end

Actual behavior
Test fails. :(
Steps to reproduce the problem
Add this case and run specs.
RuboCop version
(a41dce832c3da1b31628fdc1d707a1254ac85ee2 from master branch)
$ ./bin/rubocop -V
0.55.0 (using Parser <IP_ADDRESS>, running on ruby 2.5.1 x86_64-linux)

It checks indentation relative to the opening of its scope. I.e. this passes:
Test = Module.new do

         private

         def test; end
       end

I.e. this passes

And this is terrible for me.

And this is terrible for me.

Fair enough. I relabelled the ticket as a feature request. 🙂

Another example:
stub_const(
  'TestClassWithVeryLongName', Class.new(described_class) do
    # should I align body of class with class definition?
    # and why there are no offenses about indentation of methods?
  end
)

It looks fixed in RuboCop 0.66.


[statping] fix: additionalVolumeMounts typo + image version upgrade

Special notes for your reviewer:
fix: additionalVolumeMounts typo
chore: update to latest functional version
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [radarr])

@kalw do you think you can instead migrate this chart to use the common library which inherits this change?
You can take a look at sonarr, radarr, or other charts that use it.
Thanks


Tx history table - Date labels can be wrong in some timezones

Bug description
When there is no filter applied, the date label that groups tx in table is 1 day off from the date of the tx; A tx created.
It might have to do with the timezone. This was tested in the GMT -3.00
Environment

Browser: Chrome
Wallet: MetaMask
Chain: Any

Steps to reproduce

Go to this safe that has a bunch of tx's https://web-core.pages.dev/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history
Search for the tx on Sept 6 (the label in the table)
Hover the date in the tx

Expected result
It should also be at some time of the day on the sept 6
Obtained result
The tx are on Sept 7.
Screenshots

NOTE:
There is a case where the date in the tx and the label in the history is fine, I assume because the tx was done near midnight:

I've made another issue to remove the client-side date conversion and send the param to the backend: https://github.com/safe-global/safe-wallet-web/issues/3001

Closing. Further updates on the ticket mentioned in. https://github.com/safe-global/safe-client-gateway/issues/924#issuecomment-1852030303

@fmrsabino when I pass timezone_offset to the backend, the grouping by date becomes consistent, but the timestamps aren all shifted according the offset, so I'd have to shift them back. I think this is not correct. Timestamps should always be in UTC.

@fmrsabino when I pass timezone_offset to the backend, the grouping by date becomes consistent, but the timestamps are all shifted according the offset, so I'd have to shift them back in the frontend code. I think this is not correct. Timestamps should always be in UTC.

The goal of timezone_offset is to shift all the available timestamps with the offset so that not only the grouping works but is consistent with the transactions that it contains.

Timestamps should always be in UTC.

I don't think this is correct (at least on the API level given the query parameter to shift the timezone) but if the user wants UTC then there's no need to use timezone_offset because that would be the default.

Timestamps in their current numerical form must be in UTC, as it's their defintion: https://www.unixtimestamp.com
They do not and cannot contain the timezone information.
If we do want to send all timestamps in a specified timezone, they should be in another format, e.g. an ISO string like 2024-01-08T10:06:40+02:00 which encodes the timezone and lets JS correctly parse and format a Date object.
With the current backend response, we cannot just take a numeric timestamp and pass it to new Date(), as it will automatically adds the local timezone offset. If you shift these timestamps on the backend, the only way to undo it on the client would be to manually subtract the timezone offset everywhere where a date is displayed. It's as messy as it sounds.
So I think it's good that the backend takes a timezone_offset parameter, as it helps correctly group txs by date, but it shoudn't use that to shift UTC timestamps.

Timestamps in their current numerical form must be in UTC, as it's their defintion: https://www.unixtimestamp.com They do not and cannot contain the timezone information.

I'm aware. The issue is that there was a mismatch between how we interpret the Date headers vs the timestamps of the transactions.

If we do want to send all timestamps in a specified timezone, they should be in another format, e.g. an ISO string like 2024-01-08T10:06:40+02:00 which encodes the timezone and lets JS correctly parse and format a Date object.

While I agree with this change it's a change on the API level that we should pursue on future iterations as I'd say the timestamp field should be replaced in that case. But we can open the discussion then if we get to that point.

With the current backend response with shifted timestamps, we cannot just take a numeric timestamp and pass it to new Date(), as it will automatically add the local timezone offset. If you shift these timestamps on the backend, the only way to undo it on the client would be to manually subtract the timezone offset everywhere where a date is displayed. It's as messy as it sounds.

Yes this is messy. The goal was to use the timestamp as it is without any timezone conversion as that would be tackled by the CGW.

So I think it's good that the backend takes a timezone_offset parameter, as it helps correctly group txs by date, but it shoudn't use that to shift UTC timestamps.

I agree. @DmitryBespalov we should check how this change affects mobile. From the discussion:

timezone_offset should be used for grouping only
Timezone conversion is done on the client side.

@fmrsabino what was the reason this timestamp adjustment was introduced in the first place? Rust client didn't adjust timestamps, but just used them for grouping - that's what we had before.

@fmrsabino what was the reason this timestamp adjustment was introduced in the first place? Rust client didn't adjust timestamps, but just used them for grouping - that's what we had before.

There was an issue where the Date headers were taking into consideration the timezone offset but not the transactions under each group. This led to some inconsistencies that were reported multiple times.
There was also this (wrong) assumption that the clients would render the dates as is (no further timezone conversions). While this can work, it can lead to some confusion on what the timestamp returned actually represents as mentioned in https://github.com/safe-global/safe-client-gateway/issues/924#issuecomment-1880705387.
My suggestion: revert the timezone_offset changes and make sure that the date headers are returned in UTC so that any UNIX timestamp can and should be considered as UTC.
I will also add this to the documentation of the route so that it's more clear in the future.

Obviously, this change back to the original implementation affects mobile, too - I'll need to release new version. But, this is a minor thing and is easy to do

Yes I do understand this. Apologies for this back and forth. It was not clear on where the timezone conversion should be and I agree that given a UNIX timestamp it should be treated as a UTC (which was partially not respected in the CGW with the headers).
If we have an agreement on this: "Every UNIX timestamp should be considered as UTC" then I'd go ahead and implement these changes on the CGW side.

Let's do it

@DmitryBespalov @katspaugh there's another side effect to this change: the DATE_LABEL were previously reset to the start of the day (hours, minutes, seconds, set to 0).
However if we consider that every timestamp returned in /history endpoint follows the UTC timezone it'd be "messy" for the client side to know if the timezone offset changed the day or not.
Example: Transaction History with 2 transactions.
TX1: Sun Dec 31 2023 22:12:55 GMT+0000
TX2: Sun Dec 31 2023 23:12:55 GMT+0000
Without the timezone_offset (output sorted):

Date Label = Dec 31 2023
TX2
TX1

With the timezone_offset set to +1 hour:

Date Label = Jan 01 2024
TX2
Date Label = Dec 31 2023
TX1

However if we do follow the assumption that every timestamp returned is in UTC:

Date Label = Dec 31 2023
TX2
Date Label = Dec 31 2023
TX1

Following up the proposal of every timestamp in UTC, the Date Labels should also have the full time information. Therefore when the time conversion happens on the client side you'd correctly shift one of the labels to "Jan 01 2024" and the other one remains with "Dec 31 2023".
Thoughts?

that's exactly how it worked: we get unix timestamp, add locale information (incl. time zone), and it's displayed correctly as different dates.

that's exactly how it worked: we get unix timestamp, add locale information (incl. time zone), and it's displayed correctly as different dates.

Yes 👍 My point was more to underline the fact that this change will affect the Date Labels in such a way that instead of getting the timestamp of the date label set to midnight (00:00:00) you'd get the full time information of the transaction of that group.
On the client side the timezone should still be applied but then only the day should be rendered.

Yes, it makes sense for date labels to not be at midnight but mirror the first (or last?) timestamp of the group.

We have discovered that this issue was partially solved – daylight savings are still not taken into consideration. I've opened an issue with more details.

Researching the UTC and DST (daylight saving time), it seems that the best way to resolved the issue with DST is to use the timezone ID, like Europe/Paris instead of the timezone_offset (+1:00). This way, backend gets full information about the timezone from the clients, including the DST adjustment. If the timezone ID is not available then we can fall back to the timezone offset.
References:
https://tc39.es/proposal-temporal/docs/ambiguity.html#understanding-time-zones-offset-changes-and-dst
https://tc39.es/proposal-temporal/docs/ambiguity.html#ambiguity-due-to-dst-or-other-time-zone-offset-changes


Zachmu/fix pushdown

Bug fixes for table pushdowns and index lookups:

Failing to renumber fields in a filter after projecting a subset of columns onto tables in some cases
Incorrectly applying index lookups to OR clauses involving more than one table, which inappropriately restricts the indexed table to only matching values.

Added a couple test tables to engine_test, and broke out the tables used for information schema into their own set of test definitions.

Bug fixes for table pushdowns and index lookups:
Failing to renumber fields in a filter after projecting a subset of columns onto tables in some cases
Incorrectly applying index lookups to OR clauses involving more than one table, which inappropriately restricts the indexed table to only matching values.
Added a couple test tables to engine_test, and broke out the tables used for information schema into their own set of test definitions.


[vcpkg toolchain] Fix paths with special characters

When using execute_process and add_custom_command, the path included in the command line with special characters will break the execution process.
Fixes #24447.

@ResearchDaniel Can you please test this PR?
Thanks.

This change doesn't make sense. Fortunately, it failed early.

I think that the quotes need to be escaped inside of the other quotes? For example:
"\”${Z_VCPKG_BOOTSTRAP_SCRIPT}\"”

@ResearchDaniel I think now it's okay?

@ResearchDaniel I think now it's okay?

tested your branch and it seems to work.

This change doesn't make sense. Fortunately, it failed early.

Do you think the current one makes sense?

This change doesn't make sense. Fortunately, it failed early.

Do you think the current one makes sense?

Well, now it is what I proposed, and what CMake doc recommends.
(What didn't make sense was removing quotes which were needed for CMake syntax.)

Well, now it is what I proposed, and what CMake doc recommends.

Sorry, I didn't see such a proposal.

@JackBoosY Thanks for the fix :)


RDPWrap no longer working probably after windows update

Hi,
I'm using windows 10 Home x64. Version: 1703, Build 15063.0
It appears that after windows update, RdpWrap no longer works.
I tried:
-reinstalling,
-modifying folder permissions of program files folder of RdpWrap, to full to System and Administrators, Current user, etc.
-disabling firewall,
-uninstalling antivirus.
-tried the update method RDPWInst.exe -w
-tried the update method using the bat file.
Symptoms:
while installed, RdpWrap shows:

A few days before, rdpWrap worked like a charm, what can I say.
Cannot use windows restore as it was disabled.
Cannot uninstall all the recent updates. Some don't have the uninstall button available.
Any thoughts on this ?
Many thanks.
Joe.

Hi, this seem to have already reported, see #235

This is duplicate of #235 and #194.


Not able to successfully set up MongoKitten

I have not yet been able to successfully set up MongoKitten on my swift app, when building I get the following error.
any idea what may be causing this?
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Auth/Database+Authentication.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Auth/SCRAM.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Collection/Collection+Administration.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Collection/Collection+Geospatial.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Collection/Collection.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Database/Database+Administration.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Database/Database+RoleManagement.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Database/Database+UserManagement.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Database/Database.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Error/CRUDError.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Error/MongoError.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/Bool+String.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/BuildInfo.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/Concern.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/GeoNearOption.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/Helpers.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/LogDestination.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/SerializationHelpers.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Helpers/String+MongoKitten.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Internals/Document+CustomValueConvertible.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Internals/Flags.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Internals/Message.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Internals/MongoDriverInformation.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Internals/OperationCode.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/Cursor.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/DBRef.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/GridFS.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/Index.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/PipelineBuilder.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/Projection.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/QueryBuilder.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Querying/Sort.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Server/ClientSettings+URL.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Server/ClientSettings.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Server/Server.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Server/SSLSettings.swift'
:0: error: no such file or directory: '/Users/Meghan/Desktop/Swift Practice/TestMongo/Packages/MongoKitten-3.2.3/Sources/MongoKitten/Socket/Connection.swift'
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1

How did you attempt to install/add MongoKitten?

I added it to Package.swift and did an update

What did you add to Package.swift? Just so I can reproduce it.

Which Swift version is this? MongoKitten 3 was written for Swift 3.0 and above. The Package.swit looks fine. But the behaviour looks like Swift 2.x.

Is this still an issue?


Made window component Draggable

Gave the window a draggable prop and a default location prop, allows you to drag window freely within parent. Using React-dragable https://www.npmjs.com/package/react-draggable.

@JustinTGoodrich hey! first of all thanks for participating :) Your code looks good but I am not sure if I want to add any dependencies. I will analize it and get back to you soon!

We opted for not introducting any external dragging libraries to React95 as users might want to use different solution


Linux compile v1.1.0 failed

ERROR: /home/fesun/.cache/bazel/_bazel_fesun/c44abb322eef8ca1d3dd1c34fcda8c3a/external/io_bazel_rules_closure/closure/private/defs.bzl:27:16: The set constructor for depsets is deprecated and will be removed. Please use the depset constructor instead. You can temporarily enable the deprecated set constructor by passing the flag --incompatible_disallow_set_constructor=false
ERROR: error loading package '': Extension file 'closure/private/defs.bzl' has errors
ERROR: error loading package '': Extension file 'closure/private/defs.bzl' has errors

I added the flag --incompatible_disallow_set_constructor=false for all bazel command call, then:

DEBUG: /home/fesun/.cache/bazel/_bazel_fesun/c44abb322eef8ca1d3dd1c34fcda8c3a/external/bazel_tools/tools/build_defs/pkg/pkg.bzl:197:9: @//tensorflow/tools/lib_package:libtensorflow_jni: you provided a non dictionary to the pkg_tar files attribute. This attribute was renamed to srcs. Consider renaming it in your BUILD file.
DEBUG: /home/fesun/.cache/bazel/_bazel_fesun/c44abb322eef8ca1d3dd1c34fcda8c3a/external/bazel_tools/tools/build_defs/pkg/pkg.bzl:197:9: @//tensorflow/tools/lib_package:cheaders: you provided a non dictionary to the pkg_tar files attribute. This attribute was renamed to srcs. Consider renaming it in your BUILD file.
DEBUG: /home/fesun/.cache/bazel/_bazel_fesun/c44abb322eef8ca1d3dd1c34fcda8c3a/external/bazel_tools/tools/build_defs/pkg/pkg.bzl:197:9: @//tensorflow/tools/lib_package:clib: you provided a non dictionary to the pkg_tar files attribute. This attribute was renamed to srcs. Consider renaming it in your BUILD file.
DEBUG: /home/fesun/.cache/bazel/_bazel_fesun/c44abb322eef8ca1d3dd1c34fcda8c3a/external/bazel_tools/tools/build_defs/pkg/pkg.bzl:197:9: @//tensorflow/tools/lib_package:clicenses: you provided a non dictionary to the pkg_tar files attribute. This attribute was renamed to srcs. Consider renaming it in your BUILD file.
ERROR: /home/fesun/tensorflow/tensorflow/core/kernels/BUILD:59:14: Traceback (most recent call last):
File "/home/fesun/tensorflow/tensorflow/core/kernels/BUILD", line 54
config_setting(name = "xsmm_backward", values = {..."})
File "/home/fesun/tensorflow/tensorflow/core/kernels/BUILD", line 59, in config_setting
{"define": "tensorflow_xsmm=1", "define": "tensorflow_xsmm_backward=1"}
Duplicated key "define" when creating dictionary
ERROR: package contains errors: tensorflow/core/kernels
ERROR: error loading package 'tensorflow/core/kernels': Package 'tensorflow/core/kernels' contains errors

Any solution for this?

Try using the latest version of TensorFlow (1.3 or master) and Bazel.

Bazel had quite a few backwards incompatible changes this year, so the error is definitely due to using an incompatible bazel version. You have two options:

Use a new branch as @reedwm suggested
Or use the appropriate bazel version, as listed at the bottom of this page:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/docs_src/install/install_sources.md


How to integrate it with Vulkan Coordinate System

Hi
I'm working on integrating this amazing library with vulkan. After creating right hand projection and view matrices , I used "MaskedOcclusionCulling::TransformVertices" function to transform triangles, unfortunately, the results for those objects that view_culled were ok, but the result of those objects which occluded were not ok.
would you help me on this issue?
Here is my project on GitHub.

I just fixed it. Thanks Intel Staff for implementing this algorithm.


search by hash

design a search way just by hash
user can hash their data by their machine without doubt

Maybe this page is similar to what you want?
https://breach.tw/search_step.php


fix extended box in tools/box

maybe it is good to merge this even when we delete it afterwards (https://github.com/libjxl/libjxl/pull/2975) in the unlikely case this box file is ever revived...