blocks|key|1507167|text|我只需将多行输出生成一个字符串变量，然后从多行输出中去掉空格，并将结果放入另一个字符串变量中。如果剥离的输出大于最大行长，out()将返回多行输出。否则，它将返回已剥离的输出。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|entityMap^0|1P|5^^$0|@$1|2|3|4|5|6|7|G|8|@$9|H|A|I|B|C]]|D|@]|E|$]]]|F|$]]

I would simply produce multiline output into one string variable, and then strip whitespace from the multiline output and put the result into another string variable. If the stripped output is greater than your maximum line length, <code>out()</code> returns the multiline output. Otherwise, it returns the stripped output.

Well, I've been hammering away on this for about a week now with no practical progress because I can't find mental fluidity with the concepts I'm trying to wrangle. I'm Officially Stumped, and would humbly appreciate any insight.

Some minimal background: for several years I've used my own small PHP (CLI-only) introspection helper that provides a <code>d()</code> alternative to <code>print_r()</code> or <code>var_dump()</code>. It features type colorization (using xterm's 256 color palette), and argument literalization (<code>d($a)</code> might show <code>$a: "hi"</code>), and among other nice features, a (much) more compact output layout.

<h2>My problem</h2>

My question is to do with how the layout system decides how to present nested items. If I have input like

<pre class="lang-php prettyprint-override"><code>$a = [
 "abcde", "fghij", "klmno", "pqrst"
];

d($a);
</code></pre>

I'll get something back like

<pre><code> (test:3) $a: ["abcde", "fghij", "klmno", "pqrst"]
</code></pre>

but if I were to add a small array in the middle that would cause the output to be too long for one line, the output might change to

<pre><code> (test:3) $a: [
 "abcde",
 "fghij",
 [1, 2, 3, 4, 5],
 "klmno",
 "pqrst"
 ]
</code></pre>

This is really nice and seriously tidies up what PHP would output intermixed with a *very* large serving of line breaks.

In the example above you might notice that the outer array expands into multiline mode because it would (rightly) be too long for the line, while the inner array stays in compact mode because it (also rightly) will fit just fine.

I'm not sure if the way I used to do this was arguably terrible or arguably viable: every single <code>dump_*</code> function would speculatively re-execute itself in an assumed non-multiline mode, with the magic <code>$len_test</code> switching my internal output-buffering system into length-measurement mode. Then the magic <code>$len</code> value would contain the amount of data output, and I could straightforwardly check whether it was too long.

Like this:

<pre class="lang-php prettyprint-override"><code>function dump_string(...) {

 if (!self::$len_test) { // length test?
 self::$len_test = true; // if not, enable
 self::dump_string(...); // and re-execute ourselves
 $multiline = (self::$len &gt; LINE_LIMIT);
 self::$len_test = false; // this is the outer scope; go back to
 // text-buffering mode now
 } else {
 $multiline = false; // test length assuming no newlines etc
 // (this is the recursive/inner scope)
 }

 ...

}
</code></pre>

This method had two problems.

Firstly, not only did properties, getter functions, etc get accessed twice, objects were inconsistently double-instantiated due to the inner function being recursed into while references were held by the outer context. (To add some fun entropy, this would only happen up to the point the function realized it had emitted too much output and bailed out.) This caused <code>spl_object_id()</code> to return generally confusing and innacurate results.

Secondly, the function recursion caused the reference recursion detection elsewhere in my code to become unmanageably hairy, because it basically had to do recursion detection across its own recursion boundaries.

I've worked out a solution for both problems that moves the "is this too long" logic into the output layer and allows the <code>dump_*</code> functions to access each value/getter/property precisely once... but it introduces a huge issue of its own - it limits the is-this-block-too-long analysis to discrete blocks in a way that does not take into account the existing contents of a given line, particularly the (sometimes) large amounts of padding that lines might have in them.

Given the following example,

<pre><code> (test:3) $a: [
 [
 [
 [
 [
 ['aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa']
 ]
 ]
 ]
 ]
 ]
</code></pre>

my new approach only considers the length of the 'aaaa...', disregarding the padding at the start of the line. That line should definitely be wrapping, but as far as the new logic is concerned it doesn't need to because it's blind to the padding.

This is what I'm Officially Stumped on.

<h2>My partial solution</h2>

You may feel like tacking a crack at reasoning through the problem space before reading on.

To cut a long story short, over about 4 days of very slow mental visualization progress (I had absolutely no idea how to visualize any of this on the computer) I came up with the following.

I have an <code>out()</code> function that accepts text, a stack depth, and a display mode (<code>-1</code> = always print, <code>0</code> = only print if not in multiline mode, <code>1</code> = only multiline). I feed this function all the text I want presented for both single- and multiline modes. This function appends to a display list like this:

<pre><code>[
 [ 0, -1, " (test:3) $a: [" ], # always print | 16 0 (lengths,
 [ 0, 0, " " ], # only single-line | - explained
 [ 0, 1, "\n 0:" ], # only multiline | 23 0 below)
 [ 1, -1, "'abc'" ], # always print (level 1) | 28 5
 [ 0, 0, " " ], # only single-line | -
 [ 0, 1, "\n " ], # multiline | 31
 [ 0, -1, "]" ], # always | 32
]
</code></pre>

If only the <code>-1</code> and <code>0</code> parts of the above were printed, you'd get

<pre><code> (test:3) $a: [ 'abc' ]
</code></pre>

while if only the <code>-1</code> and <code>1</code> parts were printed, you'd get

<pre><code> (test:3) $a: [
 'abc'
 ]
</code></pre>

Next, I iterate through the display list, keeping a running total of text length for single-line (<code>0</code>) and output-anyway (<code>-1</code>) modes, per stack depth, and letting the computed length cascade up the stack depth chain. So in the example above, the length at depth 0 is 27 but is counted as 32 because it contains depth 1, which has length 5. This allows me to straightforwardly examine the text lengths per stack depth, and set a multiline flag for the outermost stack depth that is over the limit. Going back to the example above with the nested arrays, this causes the outer array to go multiline while the inner one does not. Win.

The final piece of this puzzle is that text is only emitted in multiline mode or if I set a force-flush flag (which I use just before my <code>dump()</code> routine exits). Whenever <code>out()</code> is called with a depth argument that has multiline mode set, that text is output immediately. This allows the display list to have a very small buffer: it only buffers a few KB of data at most, ever, which was a critical requirement.

Unfortunately, I see no viable way within this model to factor the padding into the length calculations. I also have no idea what besides this model would also work.

The way I reason about this model, it doesn't differentiate between

<pre><code>[[["abcde"]]]
</code></pre>

<pre><code>[
 [
 [
 "abcde"
 ]
 ]
]

</code></pre>

and

<code>[</code> <code>\n</code> <code> </code> <code>[</code> <code>\n</code> <code> </code> <code>[</code> <code>\n</code> <code> </code> <code>abcde</code> <code>\n</code> <code> </code> <code>]</code> <code>\n</code> <code> </code> <code>]</code> <code>\n</code> <code>]</code>

it's just looking at the stack depths and then enabling some text which happens to be padding as a side-effect of the text within a particular scope being too long.

(Note that I add the padding with mode <code>1</code>, which is deliberately not considered within the length computations as it would of course always be considered, for all stack depths.)

As might be discerned from the way I've written about this, this type of logic is very alien and unfamiliar to me; I don't really know what I'm doing. If there's anything I can clarify, please do let me know. And if there are any resources I can chew on to (hopefully) provoke my brain to grow/develop in ways that would be helpful to understand this kind of thing better, I would love to hear about them!

Recursive speculative display list engine - computing text length across stack boundaries

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

腾讯云开发者社区有与腾讯云相关的官方技术问答，也引入了来自Stack Overflow的优质外文问答。找寻与 递归推测显示列表引擎.跨堆栈边界计算文本长度 相关的问答，快来腾讯云开发者社区看看吧！

递归推测显示列表引擎.跨堆栈边界计算文本长度-腾讯云开发者社区-腾讯云

问递归推测显示列表引擎.跨堆栈边界计算文本长度
EN

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问递归推测显示列表引擎.跨堆栈边界计算文本长度EN