Ports: Add a port of my patch implementation :^)

[shannonbooth]

I have also tried running through the test suite, but it unfortunately seems to cause a kernel panic.

[timschumi]

I hate having to ask this bluntly, but is there any actual purpose in this? Projects made by contributors are always nice to see, and some (like e.g. citron) are doing their own thing, but I just don't see the point in adding this as a port, since it is just a third-party rewritten version of a port that we already have.

I have also tried running through the test suite, but it unfortunately seems to cause a kernel panic.

This sounds interesting though, it would be great if you could open an issue with reproduction steps.

[shannonbooth]

I hate having to ask this bluntly, but is there any actual purpose in this? Projects made by contributors are always nice to see, and some (like e.g. citron) are doing their own thing, but I just don't see the point in adding this as a port, since it is just a third-party rewritten version of a port that we already have.

Because I would like to use it in Serenity as well :^) That's by far the main one (although, I should really get around to fleshing out the serenity implementation of patch).

It's not enabled here, but I was also wanting to play around with running on serenity the test suite I've built up for patch. I run that test suite on both GNU patch and this implementation - I was thinking of using it on the serenity patch implementation some time in the future when it is more mature. Just for curiosity into portability, and to find any issues inside of Serenity LibC+kernel. There's some issue in either my test suite or serenity itself, I need to dig further.

I have also tried running through the test suite, but it unfortunately seems to cause a kernel panic.

This sounds interesting though, it would be great if you could open an issue with reproduction steps.

Yeah, planning on it. I think it is a race condition in Process or otherwhere which I was lucky enough to hit twice in a row. But I needed to switch over to Windows not long ago for work, and now my serenity instance is uber-slow. I'm guessing I needa enable some acceleration of some sort again before I can get around to making a better boog report

[AtkinsSJ]

This is a bit of a tangent, but while poking around, I noticed that Serenity's patch implementation is also written by you. 😆 Is there much of a difference between them? Maybe you could just roll your changes into our existing one.

[shannonbooth]

This is a bit of a tangent, but while poking around, I noticed that Serenity's patch implementation is also written by you. 😆 Is there much of a difference between them? Maybe you could just roll your changes into our existing one.

Ha, yeah I should definitely port across more of those changes. Honestly, I don't think I would want to do everything the exact same way - that implementation follows from what I could test of GNU patch behavior very closely, for better or worse. Some things I would want to do differently. At some stage I should work on it some more :P The core part of is it there in Serenity, I mostly should work on fleshing out the parsing some more

[timschumi]

At the end of the day, it sounds like this port would only be interesting/useful for one person only, and quite fast-moving at that. It's probably easier maintainability-wise to keep it external, similar to what we did with the sm64 port (although a simple stub .ports_include.sh or a symlink would most likely suffice).

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[stale[bot]]

This pull request has been closed because it has not had recent activity. Feel free to re-open if you wish to still contribute these changes. Thank you for your contributions!