About your Remarkup unit tests, try to rebase. Maybe related to D25559.

Small recap:

swap cases - thanks @speck - please double-accept if this is what was suggested :D

simplified logic - thanks @speck

Another good simple candidate GDPR-friendly:

I flag this as resolved since Code Differences between Phabricator and Phorge solves the problem at the moment. Also because there are no changes in upstream since 2023.

Premising that we may want to rollback 328aee033fbd, probably this line is broken:

Ouch. Probably partially my fault. Feel free to escalate this as Task under Bug Reports - close this as obsolete then

Interesting. This cannot be reproduced here in this website https://we.phorge.it? isn't it? I think no

(Please edit file Visibility to make them Public :D It's another bug ihih - thanks! <3)

remove unrelated stuff

Please also include your exact search. I think you are searching by https://foo and that is unfortunately not possible without "doing this"

Ouch

In D25118#14541, @speck wrote:

I forgot I had this requesting changes. Any idea of the performance hit in markup rendering now that PhutilURI is constructed for every link? I think its constructor does a fair amount.

minor optimization and unit tests are still happy

But in any case, it may have sense to keep a generic index on (dst, type, src) (or maybe just dst, type) in that specific order, since the UNIQUE KEY was probably a "micro-optimization" to achieve such index for queries operating on dst, or also dst and type, but all without src. This is just an opinion from an alien. Better to wait for more answers.

Your email address(es) set by you for your user account in the Phorge Project

That is private data. Nobody can access it.

add inline documentation because we can

Let's split the problems:

There is still that minor inline comment here, maybe interesting

lol

I'm quite sure the problem is limited on repeated code blocks.

Can reproduce

Apparently PhutilSortVector.php is somehow recent, 2016, without any comment about that strpos("\0", $value) that is probably not correct

I also don't understand strpos("\0", $value) since the documentation says that the second argument is the needle

remove unuseful line - thanks

OK OK. So what else? Maybe this (mention from https://secure.phabricator.com/p/epriestley/):

No brushing teeth three times a day? However it looks good to me 👍

I forgot to invite the original author. This modification would not exist without aklapper. Eternal glory to aklapper.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

Since 2023, Wikimedia Phabricator is really Phorge.

I'm not a fan of "if not nonempty". Can I swap?

Thanks avivey. Added this:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

In D25472#13979:

is ArcanistPhpunitTestResultParser now learning to parse generic "junit style xml" format?

This seems reasonable but better to find a test plan. I also tried, without success :(

I cannot reproduce this. Can you?

Thanks Roberto. If you have not time to follow-up, no problem. We can help to re-patch.

Thanks \o/ Can reproduce.

Maybe unrelated. But after we fix PhabricatorCursorPagedPolicyAwareQuery, maybe we will find a crash test also for the first two lines:

Interestingly I was able to reproduce, but only creating 101+ tasks manually and going to the next page. So after that ?after=100 is introduced.

adopt PhabricatorEnv::isSelfURI()

Thanks. Premising I have only knowledge of traits, but not mapbuilder.

Interesting. I see. Maybe expanding its controller that should be this one: