Is it time to change the name?

I live and work in the US where protests against police brutality have been ongoing for days, and coming to work this week the word "cop" has an uncomfortable feeling about it. I don't know if this has been discussed before, but out of respect for vulnerable people in the community, it might be worth considering moving away from the name RuboCop.

I second this proposal.

I also think this would be the right decision. FactoryBot provides a good precedent, and the feel of the name could even be preserved somewhat by calling it RuboLint or similar.

I wholeheartedly hope that police violence will go down drastically.
I don't feel the best way towards this goal is with blind intolerance for all cops, including virtual ones like RuboCop's. Many policemen are doing their best in difficult conditions. In many countries, cops aren't feared like they can be in some parts of the US. (Disclosure, I'm Canadian)
My hope is that the word "cop" regains the trust of people. I hope the name RuboCop remains.

I sympathise with the situation in the US and I'm truly hoping that the protests will succeed in bringing such much needed changes there (and that we'll see the end of the police violence soon). Still, I'd rather keep politics out of software, as I feel we can't put a stigma on a word due to the actions  of some misguided individuals. I live in a country with a real dictator (although not on paper), unchecked police that's just an instrument in the hands of the government, and while no one here has any fondness of the Bulgarian police as an institution or our cops, I don't have any issues with the words "police" and "cop". The fundamental idea (serve and protect) is great, but the implementation sucks.
There's also the fact that renaming projects is extremely painful, especially at the scale we're at and will bring a ton of frustration to maintainers of related projects and our end users.
I hope that everyone will accept RuboCop for what it was meant to be - a fun pun on RoboCop, and not try to charge it with any additional negative meaning. Naming is always hard, but I'm quite fond of the name RuboCop and we won't be changing it.

Hey @bbatsov I really think you should reconsider this position:

All software is political, and I think we should acknowledge that
An association with the cops will cause harm to and otherwise marginalise potential contributors.

I live in a country with a real dictator (although not on paper), unchecked police that's just an instrument in the hands of the government, and while no one here has any fondness of the Bulgarian police as an institution or our cops, I don't have any issues with the words "police" and "cop".

"works on my machine"

I echo what @penelopezone and @emilyst both said.

All software is political
And even if that wasn't true (it is) and you'd "rather keep politics out of software", then we shouldn't name software after an inherently political force in our society which has always existed to protect white supremacy.[^1]

@bbatsov I urge you to reconsider. A rename is possible. Is it a bumpy transition? Sure. Does that matter in the long run? Of course not! Does anyone remember or care anymore that Firefox was originally named Phoenix? Nah. We've moved on with our lives.
RuboCop is still pre-1.0. It's allowed to make API breaking changes. This is that.
As @awolfson noted above, FactoryGirl to FactoryBot is a great example of prior art.

In the meantime, I forked rubocop and renamed it to ruby_lint.
Here: https://github.com/ruby-lint/ruby_lint
And here: https://rubygems.org/gems/ruby_lint
And here: https://twitter.com/ruby_lint
I will happily hand over all of the those accounts to the Rubocop folks if yall agree to rename rubocop to ruby_lint (or similar[^2]).

1: See: https://crimethinc.com/2017/03/15/slave-patrols-and-civil-servants-a-history-of-policing-in-two-modes
2: ruby-lint is abandoned and archived. https://rubygems.org/gems/ruby-lint https://github.com/yorickpeterse/ruby-lint. ruby-style is also abandoned https://rubygems.org/gems/ruby-style. rubylint is available though. https://rubygems.org/gems/rubylint

If you feel like software isn't political, I recommend that you re-watch the movie that this project is named after - it's plot revolves around corrupt police forces and barriers presented to people seeking justice by software, from algorithmic policing to specifically embodying oppressive political structures in code.
This linter has been valuable for our team - but even conversations in the office note the violence implied by the name. Just think carefully about this, and remember that even Murphy doesn't want to be associated with the name in the end.

I would disagree on the note that software is not political. Facebook and Palantir are key examples of this. Others have phrased this better than me above so I will leave those comments to their merits and instead discuss a few other concerns with the name.
Cops are Enforcers, not Correctors
The reasons, in addition to the negative connotation of the word "cop", that I would consider changing this is that the gem is inherently a linter and auto-corrector. I don't really think that these align well with RoboCop or the punning to RuboCop.
If we set aside the connotations for a moment a "cop" to me is an enforcer of the law, not necessarily a corrector. Perhaps this is more the role of a guide, a mentor, or something else. The goal of RuboCop is not only in highlighting the rules but providing solutions through autocorrection.
Code Modification
Perhaps one of the most powerful features of RuboCop is its autocorrect capabilities and NodePattern syntaxes. Neither are immediately discoverable or intuitive when glancing at the name of the gem.
The sheer amount of surprise I get when I mention autocorrect to other Rubyists is concerning considering how useful it can be. I feel the name can and does hide these capabilities.
Language Parity
The name, while having uniqueness, will lead to confusion for newer developers looking for a linter, code mod, or other similar tool from other languages. Much as we do when debating features for the Ruby language we take other languages naming conventions and habits into serious consideration. I believe this should be the same for common gem names.
This can present discoverability issues. Consider Net::HTTP vs Typhoeus as an example. One is very easy to find for a lot of other language-fluent developers, the other requires domain knowledge of Ruby tooling. I think Typhoeus is a much better API and enjoy using it over the native one, but the native libraries name is far more accessible when starting from zero.

Now to be abundantly clear I do think the name can be harmful to marginalized communities, and do not mean to discount those points above in the least. I merely wished to highlight other reasons why the name of this gem may not be the best fit for the purposes it serves.

Words matter. As an industry, we're moving away from words that exclude folks (you can see this, for example, in Rails https://github.com/rails/rails/pull/33681).

I'd rather keep politics out of software, as I feel we can't put a stigma on a word due to the actions of some misguided individuals.

As long as people are using software, it will be political. There is a stigma on the word, whether we like it or not.
As you prepare for the v1.0 release, now is the ideal time to consider the name of and I encourage you to do so.

To echo @barmintor's point, no matter how you feel about policemen in general, the specific movie "Robocop" is clearly using it the word/idea an ominous and oppressive way. If your preferred feeling is "some cops are fine" or "policing in general is fine," your current name is undermining that point.
If you had named the gem "Rubycop", it would be different: it would be about cops in general. The name "Rubocop" is clearly alluding to the movie.
(I'm not suggesting "Rubycop" as a rename.)
I also like @baweaver's point that the code-autocorrect is a powerful enough feature to be worth calling out with a rename. I think he's right on that. The current name makes that surprising.

I completely understand the idea of changing the name. Especially to those who do not understand the context.
I was down on River Walk in protest of more fair policing, defunding corrupt systems, and for change. However, I find it highly offensive that anyone would even consider trying to change the name of something which was meant for good. Alex Murphy was a good cop who fought against corruption. The same kinds of corruption I am protesting against. If you're fighting to change the name Rubocop which is a pun off of Robocop because it is offensive, and you understand the context of what Robocop symbolized, then you are the very people that we are protesting against.

There's a lovely idea from Neuro Linguistic Programming that "the meaning of your communication is the response you get, not what you think you said". I'm old enough to somewhat appreciate the cheeky movie reference, and to be aware of that movie's anti-corruption message, but that's not the message many users are getting from the name, and I totally understand why.
This feels like a great opportunity to double down on the Ruby community ethos and get a ton of positive publicity by rebranding. At the same time, let's recognise that the request implies a bunch of time and even some material expense for @bbatsov (registered domain names, doc sites etc. beyond "just" renaming in code), and some help scoping that out would probably be appreciated if the request is to seem actionable.

If there are material costs associated with this I would be glad to help pay them.

I have made a gentle fork of RuboCop called rbhint: https://github.com/zspencer/rbhint
My goal here is to support parallel development in a manner that can be safely merged upstream, if at any point @bbatsov decides that it's worth rebranding. I've begun by sprouting a new namespace for rbhint and renaming the command line program.
I'm not particularly sure I know how to do a gentle refactor this large; but I'd be curious to hear what some of the folks who know ruby a bit better think about the following plan:

Sprout new public classes in the RbHint namespace that inherit from or alias the RuboCop equivalents
Begin to prioritize configuration from rbhint.yml files instead of rubocop.yml
Migrate documentation as appropriate.

Unfortunately, I'm a bit stretched too thin to do too all the work on this, but would be happy to share maintainership with others who are enthusiastic to take on this work.
P.s. Sorry @veganstraightedge - Did not see yours until I had did mine :X. I think there may be some parallels and some subtler differences in that I'd also like to shift the degree of assertiveness that rubocop brings to the table down a bit.

RuboCop is a great pun, but the name has always felt a bit authoritarian and oppressive. Especially for a Ruby tool.

Disclaimer: I'm starting to write this at 7 am in my morning, so my thoughts are a bit incoherent.

For almost a decade I've been doing pro-bono work on the style guides, RuboCop and many related projects, but all of this gets easily forgotten. You come out of nowhere, you vilify me over this, you fork the project without even discussing this idea with our team... Whatever. The US has many issues, but so does the open-source community. If even I wanted to rename the project we're talking about 300+ extensions, usages in tens of thousands of projects, messing up with search results that have been building up for years, etc, and an insane amount of work associated with this. I've made nothing out of RuboCop and now you're adding a huge pile of disappointment and frustration on top of this nothing.

This feels like a great opportunity to double down on the Ruby community ethos and get a ton of positive publicity by rebranding. At the same time, let's recognise that the request implies a bunch of time and even some material expense for @bbatsov (registered domain names, doc sites etc. beyond "just" renaming in code), and some help scoping that out would probably be appreciated if the request is to seem actionable.

@purcell It's nice to see you around! You might remember how the rename of nrepl.el to CIDER went down - this meant so much additional work and so many confused people for years, that I'd really don't want to walk this path again. And the funny thing is I'll get a lot of hate either way... A couple of years ago I had to undergo the painful process of renaming a widely used project again (tools.nrepl -> nrepl) and there are still people confused today about why there are two of them, why some deps don't work in some cases and so on.
Everyone, I understand your frustration very much. I've had my share of political activism, I truly support the cause of the people protesting in the US these days, but I think you've got no idea what you're really asking for.  I will only ask you to acknowledge the work our team has been doing for such a long time and be a bit more respectful of our time and efforts. I don't even do much Ruby myself these days, but I'm still dedicating a lot of time to RuboCop, because I love the Ruby community. Seems the feeling is not mutual.
P.S. I haven't seen RoboCop in a while, but I have a vague recollection he was a good guy, who was fighting against the oppressive system.

Don’t get discouraged because of this nonsense. Your response is appreciated and the new “forks” of this project are nothing more than cruel jokes. Wastes of time. Unbelievable that users would treat this project with such disrespect when they should know exactly what it stands for.

@bbatsov - Hey, I apologize for not being clear.  My goal is to step forward and take responsibility for doing what I can to make that path easy for you to take if you so choose.
There are two things here that are true, and I believe that we can find a happy path that bridges the two of them.
First, in the United States of America, the police force may choose to extra judiciously execute people. The probability of them getting away with it is directly related to the color of someone's skin. This is a cold truth. A brutal truth. A truth that cuts so hard that to look at it is to suffer and encourage us to skirt our eyes away and close our minds. And it's a truth that is far worse when experienced.
Second, the effort it takes to rename a project of this size is significant.  Further, it is unreasonable for those of us who live in the U.S. and make six-figure plus salaries demand you to do that work. It's a reflection of American imperialism extended into the digital sphere. Your country is not responsible for the United States problem. Your lifestyle is probably not subsidized by the companies that make billions of dollars a year on surveillance.
My goal with my fork of rbhint is not to replace RuboCop, but to do the work to reframe the project for an American reality.  Just like Ubuntu doesn't replace Debian, just reframes it for home use.
If, at some point, you want to merge the whole kit and kaboodle, I intend to make it easy to do so.
None are free until all are free.
In Solidarity, Zee

I am 100% in support of BLM and the protests, but I don't think there's any need to change the name. That would just create too much inconvenience for so little gain.

It's a fun discussion, but not applicable. Lots of people would be confused about a sudden name change.
Different people associate words in different, disparate ways.
+1 for retaining the name rubocop. Rubo, the cop, enforces the styles for use in a particular code base. That makes sense. And while I am totally in favour of US folks transitioning into a fair democracy, the name rubocop has nothing to do with any political movement and should not be attempted to tied down to one. So -1 for the threadstarter from me.

It's really interesting how so many have such strong opinions about what should and should not do. I stand with @bbatsov!
The only single comment in all of this mess being anywhere close to reasonableis @zspencer's. Because he's the only one willing to put anything on the line for a change to happen.

RuboCop has as much to do with real cops as "photocopy" or "telescope". It is a smart pun and that's about it.
@bbatsov is right, and I'd hate for the name to change.

@bbatsov Thank you for all your hard work on this gem! That cannot be said enough.
I'm just as clued into the BLM protests as anyone and have been right from when the movement originated after the Trayvon martin and Michael brown shootings.
I think something that is being subtly missed here is that the aim of the protests is to reform Police, to get them to treat us the same way as everyone else, and not to erase them from life, or history. We'll always have police, and we'll always need them ... and we should not be applying the antipathy of current events to a piece of software that has done nothing wrong :)
More importantly, police Forces all over the world could learn a thing or two from Rubocop. It de-escalates conflict while achieving compliance because we as engineers trust it as a neutral and impartial arbiter of agreed upon standards. Black lives clearly matter to Rubycop! Which is exactly why I think Rubocop should remain the name of this gem.
cheers all!

I've appreciated @bbatsov's work for years, so to see a sudden deluge of people who've contributed nothing appear out of the ether w/ the gall to order a project maintainer make a completely nonsensical breaking change is worth at least two sneers & a round of mockery.
It'd be almost funny were it not obviously hurting conscientious maintainers who care way more than they should about keeping a community of infantile finger-pointers happy. It's to be expected that those who do the least demand the most--c'est la vie--but when demands turn into cyberbullying, annoying crosses over to execrable.
As far as "cop" is concerned, police keep communities safe and uphold the law. Sometimes they fail to maintain the expected standards when dealing w/ dangerous individuals, for which they should be held accountable, but they remain the thin blue line between civilization & chaos. Moreover, police encounters are made risky by the very criminals whom the proposers of the name switch champion. Yet those who shed crocodile tears for felons seem to simultaneously celebrate the assault of business owners and smashing of shops, many of which are owned by immigrants and low-income families.

I'm going to raise a 🍺 to @bbatsov and all the other maintainers putting in work to create projects enjoyed by thousands. You deserve all the thanks in the world and none of the venom spat by those who've never lifted a finger to give back to the community.
I'm also raising a 🍺 to law enforcement everywhere risking their safety to keep rioters & looters from ruining the lives of the hard-working, law-abiding many. Unfortunately in the real world there's no Robocop to give thugs their comeuppance, only men & women who put on a uniform each morning and do their duty on behalf of ingrates who don't know right from wrong.
Finally, I raise a 🍺 to 🇺🇸, my beloved adopted country, for which I came halfway around the world. It's not the first time she's been attacked by goons, and it won't be the last, but no matter the adversity, we will carry the torch of civilization forward, and the 🔥 of liberty shall not perish from this earth!

I think "keeping politics out of software" is impossible, software is ultimately inherently political because it effects people.
That said, I really don't think renaming the project would be particularly useful or worth the significant effort it'd take. I'd be opposed to it.
Thank you @bbatsov for your work on rubocop over the years, and I'm sorry you've had to deal with this today.

and SJW appear...
this is a joke. there is also a lot of problems in the world, beside cops, should we cover also that? and the world is not USA.
let change ruby, because people in africa are being kill, for some rich white asses that needs diamonds.

alias ruby_lint=rubocop in your .bashrc

also see the hypocrisy here

ICE is using github
microsoft for decade was trying to kill open source
you beloved platform to yell to clouds like old men, twitter is promoting agressive behaviour
usa is selling weapons to anyone that wants
usa is actively ignoring climate changing
you are using iphone, that remove software is china ask them
you totally ignore Chinese oppression against the own people or color people
you totally ignore indian suppression against muslin.
And then, after decade of ignoring police brutality, blatant ignorance, you decide the best is to change one library.

This is absurd.. Glad the maintainers did not opt to rename the project.
Whatever stigma is associated with the term cop is only temporary and will soon pass..
To those who are advocating the rename, are you all suggesting that:

if there was a project named corona, it should now be renamed to something less traumatizing in the wake of the Covid-19 pandemic?
Or if in the future a nation was attacked by an extremist group named R.U.B.Y, the programming language should be renamed altogether as well??

Hands that help are holier than lips that pray.

Making token efforts at "change" in such an absurd way ... word replacementism??? ... is sad.

This is ridiculous...
The problem isn't in the word "cop".
If you want to make a difference, take a meaningful action.

Make children and raise them well. Emphasize on good education, a proper believe system and moral values.
Organize a social event and make an appeal.
Join a protest.
etc

But picking on open source projects and demand dropping the "cop" part is just nonsense.
The RuboCop project has nothing to do with the situation in the USA. Here's its mission:

We're committed to promoting the best Ruby programming practices and helping people write better Ruby applications.

Changing the name won't change the desperate situation in the USA.
You are talking about "uncomfortable feeling" and "respect for vulnerable people in the community".
How changing the name "RuboCop" will make a difference?

Or if in the future a nation was attacked by an extremist group named R.U.B.Y, the programming language should be renamed altogether as well??

Spot on, @ashmaroli

Idiocracy!

God bless the thumb democracy.

My 2 cents as a long-time rubyist (who hasn't been using ruby much recently).
 (Especially open source projects which need to be inclusive). I also like the project name as is, since it's a pun and I love puns. However, I would like to make 2 points:

This is not a political issue. Regardless of where you stand politically speaking, watching these videos online of cops beating people will make you uncomfortable. There is a stigma that associates cops with brutality and violence, it has always been there for minorities and now the whole population sees it as well. I'm writing this from Europe by the way, we have our own share of police brutality over there as well. It's not just the USA, I believe it's a worldwide issue.

Your users are clearly affected by this. What is an open source project without users, or without taking care of its users?

I would recommend to rename the project, however going with something boring like ruby-linter isn't a good idea. Why not doing a community contest to pick the next project name? You could enforce a few rules, like "the name must be a pun" etc. You could also invite people from the community to help you decide which pun is better (I know of a certain Mr Patterson who I believe would be of great help). At the end, once you have your new project name, you could re-launch the project and use the opportunity to speak out against police brutality (which again, isn't really a political statement, just something we humans should do).

ええー、この件、bbatsovとまかんどれの大人力あふれる初期消火コメントを持ってしても止められなかったの？？
すごいな、社会正義を愛してやまない方々は最初から他人の話とか聞く気はいっさい無いんだろうなぁ。
ていうかイギリス人たちがわざわざ寄ってたかって火をくべてるのはいったいなんなの……

I’ve seen a statement “Open Source should not be political” hundred times since 2014 regarding the aggression against Ukraine, where more than 10000 civilians, including kids, have been killed and more than 2 million forced to leave their homes and everything they had. What changed?  Can you even find Bulgaria on the map?
GTFO from @bbatsov he doesn’t owe you anything. You owe him

Why should it change now? Just now because you realized something many of us have known long time ago? It seems to me hypocrite for the less.
You might also want to open this issue in these 45.854 repositories currently in Github (you might be ignoring Gitlab, Bitbucket and some others) containing the word "cop" as well @gcentauri.

I disagree with everybody supporting the rename. If this means so much to you - stop using the project, fork the repo, do all the work required to change the name and advocate for adoption of your fork. Nobody owes you this, nobody has to feel offended by some word just because you do. Put in some effort or GTFO.

Congrats @bbatsov  for standing up to these bullying activists that never put a minute of their time in the great RuboCop project!

It's disgusting to read comments claiming that software is political!
Software IS NOT political and never shall be.
OpenSource software is a monument to meritocracy, where merit lies in quality of code and dedicating your time to it for free.

I don't see anyone demanding the name change, nor bullying others to make a change happen. Those who've asked for this change to happen are requesting politely, explaining their reasons calmly.
And while I don't think 'being a contributor' should be a requirement for people casting their opinions here, let's be clear: I recognise a bunch of folks who are asking for the project's name to be changed as significant contributors to Ruby open source libraries and the community. I've seen them speak or host conferences, lead the development in essential Ruby gems, and strive to make this community and broader industry smarter, more compassionate, and more welcoming. ❤
I think words matter, I think police brutality is a global issue, I think we should embrace opportunities to make our community more respectful rather than less. There's an opportunity for improvement here, and I think it should be embraced. Much like the original comment by @gcentauri I find myself feeling less and less comfortable using a tool with this name - and that's not a reflection on how useful this gem is, nor a reflection on whether @bbatsov's work is valued. Clearly, people appreciate this gem and what @bbatsov has done, because otherwise they wouldn't be here making a request.
I understand that a name change is not likely. I think that's a shame. I'll certainly be paying attention to alternative libraries.

As someone who is against abortion, I'm beginning to see a value in it. I mean obviously mothers who want to abort aren't fit to raise a kid and thereby also help the state by not burdening them with nonsense like op and op's supporters

@gcentauri
u and everybody who wants to rename this project just because there is a cop in the name should be ashamed of yourself.
I know what you should do. Fork the repo, rename it, and use that.
Dont come here and disrespect a man's years and years of hard work.

Also, @bbatsov can I request you lock this thread from further comments. You've made your decision, and there are some extremely abusive remarks being added that don't help at all.

Yeah, looks like a lot of this anger-pile-on happened because this PR got from linked here about 4.5 hours ago:
https://www.reddit.com/r/ruby/comments/gy6cza/issue_request_on_github_to_rename_rubocop_due_to/
Doesn't feel like this is going to be a very productive conversation at this point.  Maybe their parents need to be punished for not raising them well. Same goes for effeminate sjw "dudes"

Open source isn't independent of politics. But world isn't America and politics isn't same or subset of American politics.
If cops are bad in your country/system, fix that system, banning the usage of the word cop is accepting the failure

This is what happens when fathers are excommunicated, kids

This conversation is going out of hand, yet I'll give my own shot at providing something positive
Please, if you're reading this and you feel like there's a need for a fork of RuboCop, consider joining and supporting other projects, such as Standard. It's a good project, but it needs more momentum.
Being a wrapper around RuboCop, Standard refers to rubocop's docs a lot.  With your help, that can change. Improving the ecosystem around Standard will actually allow it to become independent of rubocop.
Please consider joining an existing cause. I'm also appealing to @veganstraightedge and @zspencer in a hope to join the efforts

Perhaps it's best to lock this, as the discussion/conversation is turning toxic for no good reason. The decision was made to not rename the project, and both sides have expressed their views. There really is no need for name-calling people involved in this discussion, as that only increases the heated discussion leading to nowhere.
We all have our views and opinions, but we can still convey them properly.

Please also remove the disrespectful comments by @SRGOM and @evrial. They do not represent the Ruby community.

@sunny don't offend me excluding from software community

@sunny, please don't procreate.

Yeah, I feel that the conversation here stopped being productive, so it's time to lock it. I'll just mention a few closing words:

Please, if you're reading this and you feel like there's a need for a fork of RuboCop, consider joining and supporting other projects, such as Standard. It's a good project, but it needs more momentum.

I think that's a great suggestion, as Standard has been around for a while.

My goal with my fork, rbhint, is not to replace RuboCop, but to do the work to reframe the project for an American reality. Just like Ubuntu doesn't replace Debian, just reframes it for home use.

@zspencer Thanks for the explanations! That's fine by me.
There are many other things I'd like to add, but it seems we have to lock this discussion right away as even as I'm writing this message I see things are getting way out of hand.

After some consideration I wrote an article to bring some closure to the topic.


🐛 Wrong color on back button

Light/dark color must be inverted on back button

That's on purpose. If the button is enabled, the correct color is used

That's on purpose. If the button is enabled, the correct color is used

Okay, maybe add more difference ? Like a real disabled button, because like that, this is ... unpleasant to the eye

In this scenarios I always tend to use grey as neutral color because it's both visible in both light & dark modes.
But, to be honest, I've found a little bit weird having a disabled back button. Is this something inherited from Fluent UI?

@henry2man take a look at the Settings app. If you haven't navigated yet, the back button is disabled!

@henry2man take a look at the Settings app. If you haven't navigated yet, the back button is disabled!

@bdlukaa Maybe I haven't explained myself well. What I find weird is having a back button disabled because in reality I would expect to see no button at all.

What I find weird is having a back button disabled because in reality I would expect to see no button at all.

The button is disabled because there should be a "back" functionality. When pressing that button, any navigation previosly executed, either by Navigator.push or by changing the index on NavigationPane, should be undone. Learn more


⚠ Bofrost.at has degraded performance

In 99ef693, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1419 ms

Resolved: Bofrost.at performance has improved in fd6dc4c after 6 minutes.


[WIP] Added support for riscv64 based devices

Type of Change

[X] New feature
[ ] Bug fix
[ ] Documentation update
[ ] Refactoring
[ ] Hotfix
[ ] Security patch
[ ] UI/UX improvement

Description
I see that riscv64 support isn't there.
Testing
No testing has been done as I don't own a device with a RISCV based processor.
Impact
No bigger impact.
Issues / other PRs related
No issues.
Checklist

[X] My code adheres to the coding and style guidelines of the project.
[X] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[X] My changes generate no errors/warnings/merge conflicts.

@Umeaboy Draft the PR if it's WIP.

Draft the PR

Draft? You mean summarize it?

Draft? You mean summarize it?

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request

@Umeaboy click "Convert to draft"

@Umeaboy click "Convert to draft". You have to reopen first.

If I'm not mistaken, nobody but @ChrisTitusTech can reopen closed PR's.

If I'm not mistaken, nobody but @ChrisTitusTech can reopen closed PR's.

You are mistaken. Only the user who closes a PR (or has write access) can reopen it.

Just open a new one. And make it a draft PR.

And @Titus Tech Talk closed it.
Hence meaning that I can't reopen it no matter how much I would like to.
/Kristoffer
19 sep. 2024 22:00 av @.***:

If I'm not mistaken, nobody but >> @ChrisTitusTech https://github.com/ChrisTitusTech>>  can reopen closed PR's.

You are mistaken. Only the user who closes a PR (or has write access) can reopen it.
—
Reply to this email directly, > view it on GitHub https://github.com/ChrisTitusTech/linutil/pull/529#issuecomment-2362069658> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/AAFON2MZTHMAN55FXTOUZOLZXMUNFAVCNFSM6AAAAABOQMWFFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRSGA3DSNRVHA> .
You are receiving this because you were mentioned.> Message ID: > <ChrisTitusTech/linutil/pull/529/c2362069658> @> github> .> com>


when I run the given test example with my dataset, I got the following error, could you help me figure out the reasson

[@nmyjs_176_104 tensor2tensor]# sh -x test.sh

PROBLEM=wmt_ende_tokens_32k

MODEL=transformer

HPARAMS=transformer_big_single_gpu

DATA_BASE=/search/odin/liuqi/tensor2tensor/data

DATA_DIR=/search/odin/liuqi/tensor2tensor/data/t2t_data

TMP_DIR=/tmp/t2t_datagen

TRAIN_DIR=/search/odin/liuqi/tensor2tensor/data/t2t_train/wmt_ende_tokens_32k/transformer-transformer_big_single_gpu

DECODE_FILE=/search/odin/liuqi/tensor2tensor/data/t2t_data/decode_this.txt

BEAM_SIZE=6

ALPHA=0.6

t2t-trainer --data_dir=/search/odin/liuqi/tensor2tensor/data/t2t_data --problems=wmt_ende_tokens_32k --model=transformer --hparams_set=transformer_big_single_gpu --output_dir=/search/odin/liuqi/tensor2tensor/data/t2t_train/wmt_ende_tokens_32k/transformer-transformer_big_single_gpu --train_steps=0 --eval_steps=0 --worker_gpu=1 --decode_batch_size=10 --decode_beam_size=6 --decode_alpha=0.6 --decode_from_file=/search/odin/liuqi/tensor2tensor/data/t2t_data/decode_this.txt
INFO:tensorflow:Creating experiment, storing model files in /search/odin/liuqi/tensor2tensor/data/t2t_train/wmt_ende_tokens_32k/transformer-transformer_big_single_gpu
INFO:tensorflow:datashard_devices: ['gpu:0']
INFO:tensorflow:caching_devices: None
INFO:tensorflow:Using config: {'_model_dir': '/search/odin/liuqi/tensor2tensor/data/t2t_train/wmt_ende_tokens_32k/transformer-transformer_big_single_gpu', '_save_checkpoints_secs': 600, '_num_ps_replicas': 0, '_keep_checkpoint_max': 20, '_tf_random_seed': None, '_task_type': None, '_environment': 'local', '_is_chief': True, '_cluster_spec': <tensorflow.python.training.server_lib.ClusterSpec object at 0x4eaaa10>, '_tf_config': gpu_options {
per_process_gpu_memory_fraction: 1.0
}
, '_num_worker_replicas': 0, '_task_id': 0, '_save_summary_steps': 100, '_save_checkpoints_steps': None, '_evaluation_master': '', '_keep_checkpoint_every_n_hours': 10000, 'master': '', 'session_config': allow_soft_placement: true
graph_options {
optimizer_options {
}
}
}
INFO:tensorflow:Performing Decoding from a file.
INFO:tensorflow:Getting sorted inputs
INFO:tensorflow: batch 101
INFO:tensorflow:Deocding batch 0
Traceback (most recent call last):
File "/usr/bin/t2t-trainer", line 5, in
pkg_resources.run_script('tensor2tensor==1.0.9', 't2t-trainer')
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 540, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1462, in run_script
exec(script_code, namespace, namespace)
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 41, in exec
exec("""exec code in globs, locs""")
File "", line 1, in
File "/usr/lib/python2.7/site-packages/tensor2tensor-1.0.9-py2.7.egg/EGG-INFO/scripts/t2t-trainer", line 83, in
File "/usr/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "/usr/lib/python2.7/site-packages/tensor2tensor-1.0.9-py2.7.egg/EGG-INFO/scripts/t2t-trainer", line 79, in main
File "build/bdist.linux-x86_64/egg/tensor2tensor/utils/trainer_utils.py", line 246, in run
File "build/bdist.linux-x86_64/egg/tensor2tensor/utils/trainer_utils.py", line 543, in run_locally
File "build/bdist.linux-x86_64/egg/tensor2tensor/utils/trainer_utils.py", line 647, in decode_from_file
File "/usr/lib/python2.7/site-packages/tensorflow/python/util/deprecation.py", line 289, in new_func
return func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 590, in predict
as_iterable=as_iterable)
File "/usr/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 883, in _infer_model
features = self._get_features_from_input_fn(input_fn)
File "/usr/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 863, in _get_features_from_input_fn
result = input_fn()
File "build/bdist.linux-x86_64/egg/tensor2tensor/utils/trainer_utils.py", line 727, in _decode_batch_input_fn
File "build/bdist.linux-x86_64/egg/tensor2tensor/data_generators/text_encoder.py", line 223, in encode
File "build/bdist.linux-x86_64/egg/tensor2tensor/data_generators/text_encoder.py", line 251, in _tokens_to_subtokens
File "build/bdist.linux-x86_64/egg/tensor2tensor/data_generators/text_encoder.py", line 295, in _escaped_token_to_subtokens
AssertionError

This is hopefully corrected in 1.0.11. please give it a try. I'm closing for now, please reopen if you still see the issue.

@lukaszkaiser . It seems not helpful after update tensor2tensor to version 1.0.11. The same problem appear again.

@lukaszkaiser  @lqfarmer   My tensor2tensor version is 1.0.12, I also encounter this problem. But it works ok when I use old tensor2tensor version 1.0.9.   So I check the code difference, it's due to the assert of line 295 in file tensor2tensor/data_generators/text_encoder.py, There is no subtoken for special tokens like (one's, it's). I change it back to 1.0.9 and it works normally now!

Hmm, did you re-generate the vocabulary with the newer tensor2tensor? I think it'd be a good idea to grab 1.0.13 and re-generate the whole data from scratch. It doesn't take that long (except for the download, but you might already have it in $TMP), and it should (hopefully) work all ok. Can you check and let us know? If it still fails, can you paste the sequence of commands you run? Thanks!

Thank you, It works.

Thanks!


TODO: vite-node-miniflare

Remaining issues from

https://github.com/hi-ogawa/vite-plugins/pull/123

[x] cjs dep pre-bundling (https://github.com/hi-ogawa/vite-plugins/pull/128)

Interesting. It seems nodejs is actually using this https://github.com/nodejs/cjs-module-lexer (found via evanw/esbuild#442 (comment))
esm.sh ended up with own solution https://github.com/esm-dev/esm.sh/tree/main/packages/esm-cjs-lexer
but this requires handling re-exports between cjs as an extra steps... direct execution is fine then?
[x] cache https://github.com/hi-ogawa/vite-plugins/pull/139

[x] debug mode for vite-node (https://github.com/hi-ogawa/vite-plugins/pull/129)

need to somehow inject DEBUG=vite-node:client:execute etc...

[x] error stack trace https://github.com/hi-ogawa/vite-plugins/pull/144
[ ] integrate wrangler dev (use unstable_dev api instead of Miniflare?)
[ ] demo

[x] vite-grob-routes https://github.com/hi-ogawa/vite-plugins/pull/132

[x] virtual module
[x] react-router

[x] remix https://github.com/hi-ogawa/vite-plugins/pull/134

[x] custom RPC for DevServerHooks
[ ] custom virtual module invalidation

[x] integrate miniflare service (e.g. kv)

[ ] rename package vite-node-workerd?
[x] organize demo into separate workspaces

otherwise @hiogawa/vite-node-miniflare's devDependencies are becoming too messy
https://github.com/hi-ogawa/vite-plugins/pull/138

[ ] use h3 instead of hattip for internal? https://github.com/hi-ogawa/vite-plugins/pull/135
[x] replace vite-node with vite runtime https://github.com/hi-ogawa/vite-plugins/pull/155
[ ] handle HMRPayload in real time (websocket, birpc, sse?)

https://github.com/sapphi-red/vite-envs/tree/use-vite-runtime

[x] redirect response is stuck in miniflare.dispatchFetch?

https://github.com/cloudflare/workers-sdk/issues/5018

Hey, just found your repo and wanted to say that I think you're doing really awesome work. It's been a long struggle to find something with great DX to develop full stack React apps on Cloudflare with Vite, and it looks like you're working on literally every problem with that right now.
Maybe this isn't something you're interested in, but to me it looks like you've got all the ingredients for a mini framework to do React on Cloudflare workers, something that now abandoned https://github.com/flareact/flareact was aspiring to. I'll be playing with your fuller react-router / HatTip example with that in mind.
Either way, please keep up the great work and I'll be watching closely! Would love to contribute as well if you get to a point where that makes sense to you.

@alexturpin Thanks for the interest! This package vite-node-miniflare was mostly an early experiment and I'm not actively developing it other than giving some feedback to Vite team.
The good new is that, in Vite 6, they are planning to include a new feature to allow non-NodeJs runtime integration easier and indeed collaborating with Cloudflare team on this aspect, so you might want to follow the development there. Please check out a following discussion and if you have any feedback, please feel free to comment!

https://github.com/vitejs/vite/discussions/16358
https://github.com/vitejs/vite/pull/16471

Let me close this issue for now as it's a bit obsolete and it served its purpose.

@hi-ogawa totally understand, thanks for taking the time to respond! I think I've actually found a pretty ideal solution in HonoX which leverages the new workerd getPlatformProxy.

Right, getPlatformProxy is the current solution by Cloudflare team, but they are now exploring to bring genuine workerd runtime for the entire server side code during development (not only cf resource bindings).
You can find some early proof of concepts here if you are interested

https://github.com/dario-piotrowicz/vite-environment-6.0.0-alpha-experimentations
https://github.com/jacob-ebey/cf-vite-plugin
https://github.com/hi-ogawa/vite-environment-examples


Add status channels

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?
This PR adds status channels to the Routing and Faulting Custom Device.
Why should this Pull Request be merged?
Status channels are useful for monitoring engine status.
What testing has been done?
Compile and deploy the Routing and Faulting Custom Device without error.

This PR blatantly borrows code from the SLSC Switch Custom Device to initialize and compile the status channels. With the exceptions of the constants and return types the code is exactly the same. We should consider moving this code to a shared location to reduce code duplication.

[ ] I think you can revert the changes to the lvproj file, they look like noise.

[ ] I would prefer these be part of Constants.vi, but both #46 and #47 are already conflicting on that file, so leave it be.


Error during compiling

Hello,
Unfortunately, the compilation process failed for me.
I got the following error messages. Hope it helps.
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/go_scripts.cpp.o
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/guards.cpp.o
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/item_scripts.cpp.o
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/mob_generic_creature.cpp.o
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/npc_innkeeper.cpp.o
[ 98%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/npc_professions.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/npc_stave_of_ancients.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/npc_taxi.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/npcs_special.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/player_scripts.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/server_mail.cpp.o
[ 99%] Building CXX object src/server/scripts/CMakeFiles/scripts.dir/World/world_script_loader.cpp.o
[ 99%] Linking CXX static library libscripts.a
[ 99%] Built target scripts
Scanning dependencies of target worldserver
[ 99%] Building CXX object src/server/apps/CMakeFiles/worldserver.dir/worldserver/CommandLine/CliRunnable.cpp.o
[ 99%] Building CXX object src/server/apps/CMakeFiles/worldserver.dir/worldserver/Main.cpp.o
[ 99%] Building CXX object src/server/apps/CMakeFiles/worldserver.dir/worldserver/RemoteAccess/RASession.cpp.o
[ 99%] Building CXX object src/server/apps/CMakeFiles/worldserver.dir/worldserver/ACSoap/ACSoap.cpp.o
[100%] Linking CXX executable worldserver
/usr/bin/ld: ../../../modules/libmodules.a(ModulesLoader.cpp.o): in function `AddModulesScripts()':
ModulesLoader.cpp:(.text+0x12): undefined reference to `Addmod_DungeonRespawnScripts()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [src/server/apps/CMakeFiles/worldserver.dir/build.make:171: src/server/apps/worldserver] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1028: src/server/apps/CMakeFiles/worldserver.dir/all] Error 2
gmake: *** [Makefile:149: all] Error 2

real    60m32.656s
user    339m39.792s
sys     18m53.866s

Rename the folder from mod-DungeonRespawn to DungeonRespawn

Okay, will do. I guess it's my fault. I'm sorry.
Thanks for the quick reply.

No problem.


Should I expect webpack-proxy to work?

Hi, I tried to get the functionality in  server/middleware/webpack-proxy.js to work, but it seems I'm missing something. It explodes with the following stacktrace:
TypeError: requestThunk is not a function
at Object. (webpack-proxy.js:113:19)
at /home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:137:8
at new Promise (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/core-js/modules/es6.promise.js:197:7)
at Object.thunkToPromise (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:135:10)
at Object.toPromise (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:119:55)
at next (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:99:29)
at onFulfilled (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:69:7)
at /home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:54:5
at new Promise (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/core-js/modules/es6.promise.js:197:7)
at Object.co (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:50:10)
at converted (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/koa-convert/index.js:17:15)
at dispatch (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/koa-compose/index.js:41:32)
at next (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/koa-compose/index.js:42:18)
at createGenerator (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/koa-convert/index.js:24:16)
at [object Generator].next (native)
at onFulfilled (/home/tarjei/htdocs/frisvold/fistup/ask/node_modules/co/index.js:65:19)

I had the same issue, and switched to use Koa-proxy

To be honest I haven't tested it in a while, it was a PR for a use case that I don't commonly use, and without tests I've only really been hoping that it does work. If you have a better alternative I'd love a PR; if not I'll look at fixing it/switching.

Based on https://github.com/koajs/koa/issues/198 I ended up with this:

import Koa from 'koa'
import convert from 'koa-convert'
import webpack from 'webpack'
import webpackConfig from '../build/webpack.config'
import historyApiFallback from 'koa-connect-history-api-fallback'
import serve from 'koa-static'
import _debug from 'debug'
import config from '../config'
import webpackProxyMiddleware from './middleware/webpack-proxy'
import webpackDevMiddleware from './middleware/webpack-dev'
import webpackHMRMiddleware from './middleware/webpack-hmr'

import httpProxy from 'http-proxy'
import http from 'http'
import url from 'url'

let proxy = null

const debug = _debug('app:server')
const paths = config.utils_paths
const app = new Koa()

// This rewrites all routes requests to the root /index.html file
// (ignoring file requests). If you want to implement isomorphic
// rendering, you'll want to remove this middleware.
app.use(convert(historyApiFallback({
  verbose: false
})))

// ------------------------------------
// Apply Webpack HMR Middleware
// ------------------------------------
if (config.env === 'development') {
  const compiler = webpack(webpackConfig)

  // Enable webpack-dev and webpack-hot middleware
  const {
    publicPath
  } = webpackConfig.output

  if (config.proxy && config.proxy.enabled) {
    const options = config.proxy.options
    proxy = httpProxy.createProxyServer(options);
      //    app.use(convert(webpackProxyMiddleware(options)))
  }

  app.use(webpackDevMiddleware(compiler, publicPath))
  app.use(webpackHMRMiddleware(compiler))

  // Serve static assets from ~/src/static since Webpack is unaware of
  // these files. This middleware doesn't need to be enabled outside
  // of development since this directory will be copied into ~/dist
  // when the application is compiled.
  app.use(convert(serve(paths.client('static'))))
} else {
  debug(
    'Server is being run outside of live development mode. This starter kit ' +
    'does not provide any production-ready server functionality. To learn ' +
    'more about deployment strategies, check out the "deployment" section ' +
    'in the README.'
  )

  // Serving ~/dist by default. Ideally these files should be served by
  // the web server and not the app server, but this helps to demo the
  // server in production.
  app.use(convert(serve(paths.base(config.dir_dist))))
}

const server = http.createServer(function (req, res) {
  var path = url.parse(req.url).pathname
  if (proxy !== null && /^\/api\/.*/.test(path)) {
    let host = req.headers.host.replace(/:.+/, '')
    return proxy.web(req, res, {
      headers: {
        host: host
      }
    })
  }
  app.callback(req, res)
})

export default server

Please note that I have updated the code above once to fix a hang.

@tarjei sorry for the slow response, but in case you're curious there's been a fixed pushed to master for this: https://github.com/davezuko/react-redux-starter-kit/commit/9327561cac2e128c272090087a79cb785af45c41.
Thanks for the bug report and detailed walkthrough.

Hi, did you test this? AFAIK koa-proxy does not work with koa 2.0. I tried going that route before the solution detailed above.

@tarjei koa-proxy works for me, by transform from koa-converter
// koa-proxy
  if (config.proxy && config.proxy.enabled) {
    app.use(convert(proxy(config.proxy.options)))
  }

OK, it didn't for me but I'll investigate some more later :)
Thanks
2016-03-01 6:06 GMT+01:00 Chen Fang<EMAIL_ADDRESS>
@tarjei https://github.com/tarjei koa-proxy works for me, by transform
from koa-converter
// koa-proxy
if (config.proxy && config.proxy.enabled) {
app.use(convert(proxy(config.proxy.options)))
}
—
Reply to this email directly or view it on GitHub
https://github.com/davezuko/react-redux-starter-kit/issues/558#issuecomment-190548450
.

--

Tarjei Huse
Mobil: 920 63 413

@tarjei I did test it and it worked perfectly on my end. If you are having issues let me know and I can try to help debug.


Site.find_for_request doesn't deal with IPv6 hostnames

I suggest django.http.requests.split_domain_port.
We have this:
hostname = request.get_host().split(':')[0]

but we could do this:
hostname, port = split_domain_port(request.get_host())

Currently splitting the hostname by : will erroneously take the first chunk of an IPv6 address. As a reminder, they look like this: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:443 and could be with or without the port. split_domain_port works around this.

Merged in via #5997


Add configuration files for users

create a configuration folder and configuration files so users can define the default width and height of their screen without having to use the -w and -h commands every time they run books

a configuration file is now created in ~/.books/configuration/config.cfg by configuration.sh
The file takes the format:
width=## height=##
by default width=70 and height=28
using -w and -h overrides these values.
If no cfg file is found, the default is width=70 and height=28


[ANGLE] Add fallback control options and defaults.

[macOS] Use ANGLE by default if engine is built with statically linked ANGLE.

macOS OpenGL is deprecated and buggy, using ANGLE should be more compatible.

[Windows] Add option enable/disable fallback to ANGLE and option force specific GPU to always use ANGLE.

Automatic fallback to ANGLE might be undesirec in some cases (e.g., in case of OpenXR which doesn't support it).
Some older Intel integrated devices have extreamly bad OpenGL support, but still have OpenGL 3.3 listead as supported so automatic fallback won't work in this case, and it might be necessery to workaround it.

[macOS] Use ANGLE by default if engine is built with statically linked ANGLE.

macOS OpenGL is deprecated and buggy, using ANGLE should be more compatible.

Hm. We recently added support for OpenXR on MacOS (see https://github.com/godotengine/godot/pull/79614), and while I'm still not totally sure how ANGLE will interact OpenXR, I'm assuming it won't work (either a crash or an error).
Is there an option to disable falling back to ANGLE on MacOS too? Or, is that just for Windows?
/cc @BastiaanOlij

Is there an option to disable falling back to ANGLE on MacOS too?

There's no fallback, macOS always pretend to have support for 3.2.

We recently added support for OpenXR on MacOS (see https://github.com/godotengine/godot/pull/79614)

It seems like it's not enabled for OpenGL, only for Vulkan.

It seems like it's not enabled for OpenGL, only for Vulkan.

Ah, I think you're right, based on the SCsub change on that PR. I actually thought it was the other way around since Vulkan isn't natively supported on MacOS :-)

@bruvzg congrats on the merge. Re OpenXR, we should have a chat, if Angle supports the multiview support, it should be easy to add OpenXR support for DirectX over Angle. Doing so would also be a good prelude to having this work once the DirectX native drivers become available.


App is not working at all currently

I've copied the code into a custom html app (have done it many times for many other apps, so I don't think it's user error). Nothing shows up, also no errors.
The last checkin was over a year ago, so maybe some updates have obsoleted it? This seems like a really useful app so hope that someone will bring it back to life or that Rally will implement similar app off-the-shelf.

Yea, I get an error:

Uncaught TypeError: Cannot read property 'substring' of undefined

Just found this and copied to the custom html app, same here. Sad to see there has been no fix.

If someone could fix this it would be much appreciated.


HDMI

Tenho o mesmo note, vc conseguiu deixar o HDMI 100%??? o meu só falta isso.

i am sorry i don't understand what you said.

He said: I have the same instructions, you managed to keep 100% of THE HDMI? Mine just lacks it.

I have not tried an external monitor, so i don't know how to fix this problem. Sorry.


Sonarr's CI latest script is not valid anymore

Develop and latest are currently both v4 as of today (December 30th).

Fixed in https://github.com/onedr0p/containers/commit/c792a1e76ec70083d3b96274768f0a63d1e8955c


Create bestCSS.js

The code should be readable - it appears you've minified it. Please add another pull request with the unminified code.


feat: add dictionary encoding to lance

Ref #2347

Codecov Report
Attention: Patch coverage is 89.45233% with 52 lines in your changes missing coverage. Please review.

Project coverage is 79.72%. Comparing base (4a114b2) to head (bb60df9).
Report is 4 commits behind head on main.

Files
Patch %
Lines

rust/lance-encoding/src/encodings/utils.rs
84.57%
32 Missing and 1 partial :warning:

...ance-encoding/src/encodings/physical/dictionary.rs
94.00%
6 Missing and 7 partials :warning:

rust/lance-encoding/src/encoder.rs
86.95%
1 Missing and 5 partials :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2409      +/-   ##
==========================================
- Coverage   79.83%   79.72%   -0.12%
==========================================
  Files         207      209       +2
  Lines       58806    59430     +624
  Branches    58806    59430     +624
==========================================
+ Hits        46950    47380     +430
- Misses       9120     9253     +133
- Partials     2736     2797      +61

Flag
Coverage Δ

unittests
79.72% <89.45%> (-0.12%)
:arrow_down:

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

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

For future reference - decoding seems to be the bottleneck (rather than scheduling) in terms of performance
One thing we could optimize if the decoding structure changes later is not returning a Vec<BytesMut> in decode() in dictionary.rs, since that require creating an unnecessary copy. However this would require changing the workflow for all physical decoders.


[rfc] Spec Proposal: Request Link

Abstract
This is a new proposal for an extension to the Solana Pay specification. No consensus or implementation exists.
This proposal draws in part from https://en.bitcoin.it/wiki/BIP_0072, relying on HTTPS for transmitting and authenticating arbitrary transaction payloads.
Motivation
There are a some significant shortcomings of the simple BIP21-based payment link scheme described in the Solana Pay specification.
1. It only describes simple native SOL and SPL token transfers.
Merchants, service providers, and apps may wish to mint NFTs or transfer reward tokens with purchases, invoke programs, pay gas for customer transactions, and enable many other use cases that may be developed with arbitrary transactions.
Transactions on Solana must specify the accounts that will be included in the transaction upfront. Most useful instructions require the wallet signer address, their auxiliary token account address, etc.
This requires knowing the wallet address and being able to generate PDAs from it, which cannot be known when the link is created. In short, it's missing a sessionless "connect wallet" function.
2. Payment requests are not authenticated.
We may expect that payment links will be maliciously or accidentally misused. Without knowing who a receiving address belongs to, it's not possible to determine from the URL who is requesting the payment.
A mechanism such as an HTTPS link allows the wallet to authenticate the source of the request. There may be other mechanisms we should consider.
Proposal
I propose to add an optional request=<url-encoded-url> query parameter to the specification.
An interactive protocol between the merchant and wallet follows:

The merchant presents a QR code with the following payment link:

solana:<recipient>?request=https%3A%2F%2Fmerchant.com%2Fsolanapay

Any of the parameters of the spec can also be included. <recipient> could be considered optional. Perhaps an invalid address (e.g. a, x, or _) could be provided for compatibility.
Regardless, it must not be used by the wallet if request is provided, so providing an invalid recipient address ensures a wallet will not prompt a user to make a payment unless it can handle the request parameter.

The customer scans the QR code and opens their wallet app.

The wallet parses link and prompts the user to make a request to https://merchant.com/solanapay.

This is analogous to connecting a wallet to a dapp, so obtaining the user's permission is important for privacy.

If permitted, the wallet makes a request to

https://merchant.com/solanapay?from=<wallet>&<...params>

The wallet should include any parameters from the URL provided, except for the request parameter.

The merchant responds with a JSON object:

{"transaction":"<transaction>"}

The transaction property value must be a base64-encoded serialized transaction.
The feePayer, recentBlockhash, nonceInfo, and signatures fields are optional but may be included. If they are included, the wallet must use them in the final transaction, since the transaction may be partially signed and subsidized by the merchant.
The wallet should allow additional fields in the JSON object, which may be added by future specifications.

The wallet deserializes the transaction, simulates it, and presents it for signing.

The wallet may wish to display the domain the request came from, and may wish to show payment requests not including a request parameter as unauthenticated.

The user signs the transaction and the wallet sends and confirms it.

The merchant discovers the transaction through the reference parameter, if provided.

Breaking Changes
When using the request field, the transaction can be anything -- it doesn't even need to be a payment. It could be a transaction to receive a gift or invitation from the merchant for scanning a wallet. Even if it is a payment, the receiving address could be dynamic, or a smart contract, etc.
This means that semantically, there may be no recipient to provide. I think we should allow URLs with no recipient of the form
solana:?request=<url>

This is shorter (will encode in a lower-density QR code) and is more correct than providing a value that shouldn't be used and hoping it isn't.
BIP72 shows this as a valid, non-backward compatible example, but we don't really need to worry about backwards compatibility at this time.
This is a breaking change because the spec currently requires the recipient field value to be a public key, and I propose that we allow an empty string.

Notes
Some cool use cases this unlocks:

Merchants get an atomic bidirectional communication channel with customers. They can mint an NFT or transfer loyalty reward tokens in the transaction.
Merchants could potentially see what tokens a user has, accepting and denominating payment in any of them.
Merchants can pay for transactions on their user's behalf so they don't need SOL in a wallet.
Merchants can return an error from the server to decline to respond with a transaction. This could be used to allow permissioned payments.
Payments can be directed to escrow-like programs, enabling things like refunds, chargebacks, and other return mechanisms.
DeFi transactions could be bridged to all kinds of web2 / IRL portals.
Wallets can retrieve other information, or merchants can pass it to them, like an icon to display, or other fields in the JSON response.
It doesn't even need to be a payment. Merchants could send tokens, invitations, gifts to customers that connect a wallet, perhaps one that meets some criteria, such as possessing an NFT.

Some things I'm unsure about:

Do we need to do anything to ensure message integrity?
If merchants are co-signing the transaction, how do we prevent spam / DoS?
How can custodial exchange wallets adapt this functionality?
How do we keep users safe when arbitrary transactions are supported?

This all looks really good.  Some questions regarding your questions:

Do we need to do anything to ensure message integrity?

How is the merchant certain that the transaction is correct afterwards?  If the user just gets a plain unsigned transaction, their wallet could manipulate all sorts of things inside of it.  Will the merchant hold onto a hash of the message somewhere and check for that? Note that if the merchant signs the transaction, then this isn't a consideration since it'll get rejected by the chain.
On the subject of signatures, if the merchant signs the transaction, then the transaction must be sent within the blockhash's lifetime, roughly 2 minutes, which may be short for some use-cases, but certainly not a deal-breaker.

If merchants are co-signing the transaction, how do we prevent spam / DoS?

This could be provided at the level of the merchant API.  Before signing anything, they can do as many checks as they want on their server to be sure that they should sign this message.  For example, they can check the recipients / senders, number of transactions currently outstanding, etc.  They can even add protections to the API that generates the payment link, so that they avoid getting their wallet drained.

How do we keep users safe when arbitrary transactions are supported?

This is a bigger question not specific to this proposal.  Anytime a transaction is created for you, there's risk.  In a perfect world, the wallet would mediate all of these things to avoid exposing you to risk.  For example, a dapp instruction should almost never require a signature from your main wallet, so the wallet can check if any instructions name your wallet as a signer.  You should be able to do everything through ephemeral accounts and approves on SPL tokens.  The wallet can also add balance checks to the transaction, as discussed elsewhere.

Thanks so much for the swift review @joncinque!

How is the merchant certain that the transaction is correct afterwards? [...] Will the merchant hold onto a hash of the message somewhere and check for that?

I think so, yeah. Right now, merchants validate transactions once they discover them to verify that they contain a valid transfer of the expected amount to their address. This is a little complicated even for the simple case. I think for arbitrary transactions, they may want to just store a message hash and check it more cheaply.

if the merchant signs the transaction, then the transaction must be sent within the blockhash's lifetime

I think for the use case this feature makes sense in the context of, this is totally fine. Even a minute is a long time to wait to confirm the transaction in terms of UX, so I think the emphasis will need to be on making sure this happens quickly and reliably. Nonce accounts are something I don't know much about. Is there a way a merchant could retry a transaction with a nonce account?

Before signing anything, they can do as many checks as they want on their server to be sure that they should sign this message.

Yeah, good points. I think if the merchant has a trusted PoS that is getting permission to produce unique request URLs from a trusted service, say with a secret auth token, they can make sure they aren't getting spammed at scale, and are maybe just eating the occasional failed tx fee. This can ideally be left up to service providers to innovate on their behalf.
One thing is that the PoS app or ecommerce app will need to become aware of the transaction somehow. I can think of basically two ways --

The merchant app encodes solana:ABC?request=https://merchant.com/solanapay?reference=XYZ and polls for signatures on pubkey XYZ as it does with the current protocol. The wallet makes a request to the request link URL, which returns a transaction with some instruction referencing XYZ.
The merchant app has, say, a socket connection to the merchant API. The merchant app encodes solana:ABC?request=https://merchant.com/solanapay/UNQ where UNQ is just some opaque unique identifier for the request. The merchant API signs the tx as the fee payer, so it has the primary tx signature now. It transmits this signature to the merchant app, and now the merchant app can just reliably wait for confirmations on that tx without any reference.

My general expectation is that merchants will usually want to pay tx fees for users, and 2) produces a cleaner result / UX.

How do we keep users safe when arbitrary transactions are supported? This is a bigger question not specific to this proposal.

True. I just want to get feedback to make sure this protocol isn't adding novel attack vectors I haven't thought of.

How can custodial exchange wallets adapt this functionality?

This is potentially a can of worms -- if you're using your FTX wallet that's doing withdraws via the current version of Solana Pay, you don't have the same freedom to sign arbitrary txs that a Phantom user does.
I don't know, for example, if the merchant API will be able to see your balances. And if they want to do something like send you an NFT or novel SPL token, you're in trouble because there's a good chance the custodial exchange can't receive it.

Notes
Some cool use cases this unlocks:

Merchants get an atomic bidirectional communication channel with customers. They can mint an NFT or transfer loyalty reward tokens in the transaction.
Merchants could potentially see what tokens a user has, accepting and denominating payment in any of them.
Merchants can pay for transactions on their user's behalf so they don't need SOL in a wallet.
Merchants can return an error from the server to decline to respond with a transaction. This could be used to allow permissioned payments.
Payments can be directed to escrow-like programs, enabling things like refunds, chargebacks, and other return mechanisms.
DeFi transactions could be bridged to all kinds of web2 / IRL portals.
Wallets can retrieve other information, or merchants can pass it to them, like an icon to display, or other fields in the JSON response.
It doesn't even need to be a payment. Merchants could send tokens, invitations, gifts to customers that connect a wallet, perhaps one that meets some criteria, such as possessing an NFT.

Some things I'm unsure about:

Do we need to do anything to ensure message integrity?
If merchants are co-signing the transaction, how do we prevent spam / DoS?
How can custodial exchange wallets adapt this functionality?
How do we keep users safe when arbitrary transactions are supported?

This is great.
We are currently working through a lot of what you have laid out here via an Magento <-> Solana Pay integration.
Purchased products mint NFTs with metadata attached. Specifically for us, in a metaverse space for cross-reality interoperability.  If not 'within' the transaction, would be in parallel.

Payments can be directed to escrow-like programs, enabling things like refunds, chargebacks, and other return mechanisms.

This is an important point due to individual laws regarding 'right to withdraw' in whichever respective country applied. In the EU its 14 days, we could in theory hold funds in escrow account for this time them push it to another account after the cooling off period is over. But would be nice to have something baked into the native transaction.
Perhaps we, myself and @molotovbliss, add to this conversation in the coming days see what you think.

@jordansexton sounds good! Will git on Twitter.

Is there a way a merchant could retry a transaction with a nonce account?

The better bet is probably just to retry with a fresh blockhash. Nonces are going to be more trouble than they're worth.

My general expectation is that merchants will usually want to pay tx fees for users, and 2) produces a cleaner result / UX.

That was my thinking too, and makes the implementation cleaner!

This is super important! Request URLs are becoming a standard among payment systems like Bitpay and Anypay. They solve many problems and should be seriously adopted by SolanaPay.
One concept that might not have been addressed but which offers immense power and flexibility payments with multiple recipients. With Payment Request URLs the wallet can download a structure specifying multiple amounts to different parties, unlocking huge potential for creative payment apps that aren't simply "send one amount from one person to another". Imagine a payment at a store where the clerk is paid, the owner is paid, the banker is paid and the consignment supplier is paid all in one swipe!
Already many wallet apps have adopted the payment request URL protocol. I will follow up in a bit to make sure this powerful capability becomes a stable in Solanapay.

Imagine a payment at a store where the clerk is paid, the owner is paid, the banker is paid and the consignment supplier is paid all in one swipe!

This is a really cool application of this!
Do you have any thoughts on how, in general, custodial wallets might implement this? Their use of different withdrawal and deposit addresses and sweeping funds into cold wallets makes something flexible like this harder for them to handle.
Separately, it could also be useful to allow wallets to send additional instructions to include in the transaction. For example, a wallet can protect users by appending an instruction to assert their balance didn't change by more than an expected amount, but this wouldn't be possible if the merchant's request URL API signed the tx.
Is this something we should consider in scope or leave to future specification?

For reference and compatibility with other systems it should probably conform to the existing JSON v2 Payment Protocol documented here:
https://bitpay.com/docs/payment-protocol
Steven Zeiler
------- Original Message -------
On Saturday, February 5th, 2022 at 01:30, Jordan Sexton @.***> wrote:

Imagine a payment at a store where the clerk is paid, the owner is paid, the banker is paid and the consignment supplier is paid all in one swipe!

This is a really cool application of this!
Do you have any thoughts on how, in general, custodial wallets might implement this? Their use of different withdrawal and deposit addresses and sweeping funds into cold wallets makes something flexible like this harder for them to handle.
Separately, it could also be useful to allow wallets to send additional instructions to include in the transaction. For example, a wallet can protect users by appending an instruction to assert their balance didn't change by more than an expected amount, but this wouldn't be possible if the merchant's request URL API signed the tx.
Is this something we should consider in scope or leave to future specification?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>

The merchant might not even need to sign the transaction. However it is extremely useful for speed to for the wallet to transmit the signed transaction directly to the merchant's API so the merchant does not have to monitor the entire network for the transaction. Sent p2p in that fashion we have been able to drastically reduce payment times in-store at Anypay (for instance here https://twitter.com/AnypayX/status/1362949033095008261). Direct transmission between wallet and merchant provider is key, and part of the existing JSON Payment Protocol spec

For reference and compatibility with other systems it should probably conform to the existing JSON v2 Payment Protocol documented here: https://bitpay.com/docs/payment-protocol

Hmm, this is a lot of round trips. And also, the intent here is to return a transaction payload rather than just payment requests. Which aspects of the protocol are you thinking it should conform to?

However it is extremely useful for speed to for the wallet to transmit the signed transaction directly to the merchant's API so the merchant does not have to monitor the entire network for the transaction.

This is a good point and something we should test on Solana. Having the wallet broadcast the tx has some advantages for the UX though -- the user receives immediate feedback with confirmations, and the wallet controls how this is presented.
Let me read through this payment protocol more thoroughly!

Transaction Requests specified and implemented in #77

The most obvious thing this spec is missing is a redirect_uri.
When the merchant responds with a JSON object, it should include an additional field:
{ transaction:
redirect_uri:  }
After the transaction is signed and submitted by the wallet, the wallet should automatically forward to the redirect_uri, or have a button that says 'continue' that forwards to the redirect_uri. The redirect_uri should also have a txsig= query parm added, which the merchant could use to check the status of the transaction--although in my opinion the merchant should instead keep polling an RPC node looking for its transaction. Polling is a slower and more expensive method, but more reliable because this redirect cannot be guaranteed (the user could confirm a transaction and then exit out before the wallet redirects them).
If the user rejects the transaction, we can redirect the user back to the redirect_uri along with a txsig="fail" or some more specific error message, to let the merchant know their transaction request was declined or failed for some reason.
The advantage of this is that payment flows originating from within apps will be simpler. I can simply push 'pay with Solana' within any iOS native app, be directed to my wallet app, confirm the transaction, and then be redirected back to the success screen inside of the app. Or we can do the same thing with any web-app being viewed in a mobile browser.

Thanks @PaulFidika. This is a good point and it's something that I've been thinking about and talking with mobile wallets about. However, transaction requests aren't the only thing redirect URLs or deep links are applicable to, and there are many ways wallets might want to implement them, so right now it's been evaluated in parallel rather than blocking this feature.

I was recently looking into Wallet Connect (I wasn't familiar with it until yesterday). Why doesn't Solana just use Wallet Connect, or at least build a standard similar to it? I feel like Solana Pay is somewhat re-inventing the wheel here. I'm just wondering if there's some sort of advantage to Solana Pay over wallet-connect, or something you dislike about Wallet Connect?

Solana Pay is based on BIP 21, and this feature is based on BIP 70/72. QR codes are just one way that Solana Pay URLs may be encoded. URLs can be used with NFC, messaging protocols, app to app communication, etc.
WalletConnect 2 is a more generic chain-agnostic protocol and requires the use of relay servers. No wallets on Solana supported it (none do now, except Steak Wallet) and the spec and implementation of WC2 are incomplete.
There are issues with complexity, latency, and reliability. We considered it but chose to work with wallets to implement something simpler after evaluating its limitations with them.
However, there is WalletConnect support being added to the wallet-adapter library now. This won't supersede Solana Pay for the use cases we are focusing on though.

WalletConnect 2 is a more generic chain-agnostic protocol and requires the use of relay servers. No wallets on Solana supported it (none do now, except Steak Wallet) and the spec and implementation of WC2 are incomplete.
There are issues with complexity, latency, and reliability. We considered it but chose to work with wallets to implement something simpler after evaluating its limitations with them.

Okay interesting. Why does Wallet Connect use relay servers? Why not simply have the dapp <-> wallet communicate with each other directly using some standard format?

However, there is WalletConnect support being added to the wallet-adapter library now. This won't supersede Solana Pay for the use cases we are focusing on though.

Okay great! Will Solana wallets be adding support for wallet-connect anytime soon?

These are good questions but they aren't really in scope for this issue. I'm happy to discuss elsewhere though! I'm jordaaash#3040 on Discord, and there's a solana-pay channel there.

Closed by #77


autopilot.js: Not destroying bitnode after red pill gets installed and required hacking level achieved

Happened in BitNode 12 (don't know if it does this in other bitnodes)
Basically, once The Red Pill was installed, it hacked all servers (including w0rld_d43m0n) but did not destroy the bitnode but instead waited until the Black Operation: Operation Daedalus was complete (which happened a few hours after completing requirements for w0rld_d43m0n) to destroy it.

When was your last git-pull? This bug was presumably fixed 3 days ago in #443

Okay yeah it's working, I'll just close this.


Add missing stdint.h includes for GCC 13+

Fixes #77927.
Thanks @germanbv for finding and documenting the fixes. FYI, you could have made a PR with those changes directly :)
That being said, we're a bit peculiar with how we handle modifications to thirdparty code vendored in Godot, so I went ahead and did the PR myself.
Added patch files for v-hacd (the issue seems fixed upstream, but we're on an outdated version so making the difference clear is still important) and openxr (PR'ed the fix upstream, might be included in the next release if accepted: https://github.com/KhronosGroup/OpenXR-SDK-Source/pull/406). It's already fixed upstream in glslang so I didn't add a patch file, it will be included next time we update (it's included in #77898 which will supersede this for 4.1, but we still need the patch for 4.0 and earlier).

Cherry-picked for 4.0.4.

Cherry-picked for 3.6.


aaaa

aaaaaaaa

@RafaelSantosCardoso Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.


build(semantic-release): update to 8.2.0

Description of change
Dependency update.
Associated issue(s)
Closes #71

[x] The acceptance criteria for all associated issues have been completed, tested, and validated.

PR check-list

:white_check_mark: Please review and check the appropriate items.

1. Code standards compliance

[x] ESLint passes.

2. Code quality.

[x] The quality gateways pass with an "A" grade.

Measure
Scores

Complexity

Duplications

Issues

Maintainability

Reliability

Security

3. Test coverage

[x] The source code is 100% covered with passing specs.

4. Contributor License Agreement (CLA)

[x] I have signed the Contributor License Agreement (CLA).

:information_source: These tasks are not required to open a PR, and may be addresses while the PR is open.

Changes Unknown when pulling 67e9eb43532ae84bc79601f7951fc0d56f09ea3e on greenkeeper/semantic-release-8.2.0 into ** on master**.

Addressed by #86.


Fix docs

This change is wrong though? When you provide a class name, then we hit this line to get the filename:
https://github.com/cakephp/phinx/blob/5c28445848a1daba6883dd94f77c0feef0db3d28/src/Phinx/Console/Command/Create.php#L183
which per the comment:
https://github.com/cakephp/phinx/blob/5c28445848a1daba6883dd94f77c0feef0db3d28/src/Phinx/Util/Util.php#L103-L105


add a way to set an indentation level

Debug logs are very linear. It's often very hard to detect when a specific scope of some kind has been left. I can probably implement it without it being a breaking change. Here's my design idea:
Add set_indent and get_indent methods to the Log trait with default impls that do nothing. Add a log_indent! macro to set the log indent, increase it by one or decrease it by one depending on the args. Future work might also make it create a scope lock to decrease the scope level again at the end of the scope.
Does anything speak against doing this? Technically I could do it as a new logger impl, but it would be very tedious to repeat the entire env logger impl.
Change env_logger to indent the log message by the current level.

From the PR discussion it sounds like this functionality should not be in this crate.

Indeed. just forgot about this issue


In vue3, this bug occurs in the use？

"vue-grid-layout": "^2.3.12",
import VueGridLayout from "vue-grid-layout";  const app = createApp(App); app.use(VueGridLayout);

Try using the module vue3-drr-grid-layout, mentioned in comment

I have encountered the same problem. Have you already solved it？

@Losery1021 and @frontend-qin , this module seems to be abandoned. Can you please open an issue to module vue3-drr-grid-layout ? That one looks like to be more active.

@Losery1021 and @frontend-qin , this module seems to be abandoned. Can you please open an issue to module vue3-drr-grid-layout ? That one looks like to be more active.

only 13 star，I don't think it is a perfect solution

I'm using that one and it's written only for Vue3, not converted from Vue2 to Vue3. So, it work fine for me. The biggest pro, is the bundle size of the module, 7.12 MB vs 326 kB. It has only 13 stars, because it was published less than 2 month ago.

I'm using that one and it's written only for Vue3, not converted from Vue2 to Vue3. So, it work fine for me. The biggest pro, is the bundle size of the module, 7.12 MB vs 326 kB. It has only 13 stars, because it was published less than 2 month ago.

Okay, I'll try it.thx


Ability to render escaped underscore character

I expect these \_ characters to be displayed like this:

I'll see if I can fix that upstream https://github.com/nvim-treesitter/nvim-treesitter/blob/287ffdccc1dd7ed017d844a4fad069fd3340fa94/queries/markdown_inline/highlights.scm#L28