This is sort-of-maybe related to T11482 but I'm also not exactly sure what's step in the process is slow here.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 10 2016
I'm happy to change this if anyone comes up with good alternate wording, but I think this might be about the best we can do.
never mind I love the text area
In T11831#199501, @epriestley wrote:Also
this text
area sure
is
small now
Yeah, the upper-right action thing is a little weird since we don't use it in other applications, but it has felt OK to me once I kind of got used to it / continued being too lazy to change it.
Why can I subscribe to events? But not accept?
Wouldn't miss it for the world!
This is probably the required test:
Which interaction exactly is taking a long time?
Nov 9 2016
whew! good to hear.
Definitely there was a problem with the installation, for some reason the files got corrupted and downloading a fresh installation solved the problem.
Thanks chad. I will check if there is a problem with the installation and let you know.
Hi @kislinsk
Thanks for your answer! Sorry, I wasn't speciffic, I would like to change the default Home Page Pinned Applications for everybody. Is it possible?
Great!
Closing as Resolved since this doesn't seem actionable by the upstream without concrete reproducible steps.
/mail/ will tell you why you received any given mail.
We need to know how to reproduce bugs in order to fix them. Please take the time to give us all information needed about your environment so we can reproduce the bug. Id() missing means something is dramatically wrong with your installation, as no part of Phabricator is expected to run without access to libphutil and its functions.
For me seems to be quite good the information provided, but I try to explain myself with more details:
This report doesn't look to include reproduction information.
Yes, i manually built the pcre, enable utf8 and unicode properties.
this issue was resolved.
thanks.
Eventually building a setup check is the extent of our support here. You'll have to build/enable UTF-8 support for your system on your own.
pcretest -C
PCRE version 8.10 2010-06-25
Compiled with
No UTF-8 support No Unicode properties support Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack
I open the debug mode, on console, i found errors:
preg_replace_callback(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0
Stack trace:
preg_replace_callback called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php:189]
PhabricatorObjectRemarkupRule::apply called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupBlockRule.php:78]
PhutilRemarkupBlockRule::applyRules called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupDefaultBlockRule.php:17]
PhutilRemarkupDefaultBlockRule::markupText called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:232]
PhutilRemarkupEngine::markupBlock called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:128]
PhutilRemarkupEngine::preprocessText called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:269]
PhabricatorMarkupEngine::loadPreprocessorCaches called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:133]
PhabricatorMarkupEngine::process called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:73]
PhabricatorMarkupEngine::renderOneObject called at [/lv_code/phabricator/phabricator/src/applications/phriction/controller/PhrictionMarkupPreviewController.php:23]
PhrictionMarkupPreviewController::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/AphrontController.php:29]
AphrontController::handleRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:257]
AphrontApplicationConfiguration::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:169]
AphrontApplicationConfiguration::runHTTPRequest called at [/lv_code/phabricator/phabricator/webroot/index.php:17]
Nov 8 2016
The policies work like you expect them to. This is just like a revision saying "All Users" but not being visible to users who can't see the corresponding repository.
I think it makes more sense to have events inherit their policy from the import that created them (if they are imported events)? i.e. rather than copy policy settings on import, make the policy pull from the import similar to other systems (like how "build target" view policy is pulled from the "build" view policy).
But yeah, it is 100% not good to show this:
Okay, so I ended up having to restart my Phabricator instance to get the import to stop, then "Delete Imported Events" seemed to work right even though it took a reasonably long time to complete from the web UI (I feel like it should really be using the bulk operation infrastructure).
Oh god it's still importing even after I disabled the import and deleted events.
It's just very
important to
thoroughly explore
the applications
In my case (T9287), the dependencies are cross-repository, which I don't think we can reasonably automatically figure out.
(If we were better about figuring this out automatically -- which we may be soon -- would it be a problem at all?)
In T11833#199387, @epriestley wrote:The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".
The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".
"Earlier" / "Later" ?
Or, of course, we could do:
I think there was no web UI for this until T4788, which added both options. Prior to that, the only way to mark dependencies was by writing "Depends On" in text (which still works). So we didn't previously have anything else, unless I'm misremembering.
(I've asked a wordsmaster for help, so maybe we'll have better ideas soonish).
I was used to the "dependency" ones we had, but I agree they're not really unconfusing enough.
Our use of "parent" and "child" are consistent with Git's use of "parent" and "child", if that helps: for example, git help log discusses the ideas of "parent commits" and "child commits" in many places, and "parent revisions" and "child revisions" have the same relationship order as commits do in Git.
What specific, totally unambiguous labels would you prefer these actions to have?
The Phabricator versions you listed above are also not current. Just a reminder we only take bug reports at HEAD.
Bug reports like this are exceedingly resource intensive on the upstream and as stated, we are unlikely to look into for many years if ever. I'd be happy to accept this bug if you can duplicate the bug in a new, clean, environment and completely list out all components needed to reproduce it. Overall as no one else is reporting this, it is likely an environmental issue - so understanding what is unique in your environment vs everywhere else Phabricator is installed is important. Things to look at:
Sounds good, thanks!
In other words is your array syntax always messagekey[gender][plural] or could it also be messagekey[plural][plural] depending on the variables?
We support unlimited gender/plural variants in any order. We have a number of strings like this:
%s cannot be repeated as far as I know.
When multiple variants exist, should we export a nested structure like this?
[...]
"aBmeIEk": { "one": "%s star", "other": "%s stars" },
In T5267#199335, @epriestley wrote:Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.
At least some translators are likely familiar with $1, {{GENDER:$1|X|Y}}, and so on, right? And you have documentation on this syntax to help translators who aren't familiar with it learn it?
you can check this page, it is original phabricator page, it also cannot show in my server.
maybe the remarkup engine cannot work in my server, i don't know how to resolve it.
Here are the current internal data formats:
Could you tell me how to check the server error?
i don't find the errors on server.
Ah yea my hypothesis doesn't make 100% sense given all the rest of the text in your screenshot. Are there errors on the server?
i attached my saved webpage. The Text isn't existed the source code.
In T6653#167413, @maccath wrote:For reference and the benefit of people Googling how to configure a script and regex linter, here is a full example (using sass-lint):
.arcconfig file:
{ "linters": { // snip ... "sass": { "type": "script-and-regex", "include": "(\\.scss$)", "script-and-regex.script": "sh -c 'sass-lint -v \"$0\" || true'", "script-and-regex.regex": "(^((?P<file>.+): line (?P<line>[0-9]+), col (?P<col>[0-9]+), (?P<severity>[^\\-]*) - (?P<message>.*) \\((?P<name>[a-z\\-]+)\\))$)m" } }
Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.
I don't know a thing about the web but looks like it might be a font issue. Presumably your setup has the monospaced font available for use in codeblocks, but not the regular text one.
I'll have to update my instance first to test your patch, since it seems to be for newer version as you said earlier. I installed this from FreeBSD ports system, have to first convert it to normal git based install.
Some of the terms that I use below (e.g. outdated) are explained in https://www.mediawiki.org/wiki/Help:Extension:Translate/Glossary
