“Dynamic variables” table is broken

[AlexDaniel]

See https://docs.perl6.org/language/variables#Dynamic_variables

Ping @molecules

The problem occurs because of this:

    ------------------+--------------------------------------------
    $*SCHEDULER       | A L<ThreadPoolScheduler> object representing the current default
                      | scheduler.
                      |
                      | Note on usage: For the current Rakudo, by default this imposes a
                      | maximum of 16 threads on the methods C<.hyper> and C<.race>. To change
                      | the maximum number of threads, either set the environment variable
                      | RAKUDO_MAX_THREADS before running perl6 or create a scoped copy
                      | with the default changed before using C<.hyper> or C<.race>:
                      |
                      | my $*SCHEDULER = ThreadPoolScheduler.new( max_threads => 64 );
                      |
                      | This behavior is not tested in the spec tests and is subject to change.
    ------------------+--------------------------------------------

If you change it to this, then it works, but of course it does not look as nice:

    ------------------+--------------------------------------------
    $*SCHEDULER       | A L<ThreadPoolScheduler> object representing the current default
                      | scheduler.
                      | Note on usage: For the current Rakudo, by default this imposes a
                      | maximum of 16 threads on the methods C<.hyper> and C<.race>. To change
                      | the maximum number of threads, either set the environment variable
                      | RAKUDO_MAX_THREADS before running perl6 or create a scoped copy
                      | with the default changed before using C<.hyper> or C<.race>:
                      | my $*SCHEDULER = ThreadPoolScheduler.new( max_threads => 64 );
                      | This behavior is not tested in the spec tests and is subject to change.
    ------------------+--------------------------------------------

Is there any way to have paragraphs inside a table cell?

[ShimmerFairy]

While the parsing is definitely broken, note that table cells are meant to act like implicit =para blocks. So even when Pod parsing is fixed, multiple paragraphs would by definition not happen. Basically, whatever happens when you try typing multiple visual paragraphs inside a =begin para ... =end para block is what should happen in that table cell.

[tbrowder]

At least it's lookong a bit better after my last tweak.

On Sunday, July 24, 2016, Faye notifications@github.com wrote:

While the parsing is definitely broken, note that table cells are meant to
act like implicit =para blocks. So even when Pod parsing is fixed, multiple
paragraphs would by definition not happen. Basically, whatever happens when
you try typing multiple visual paragraphs inside a =begin para ... =end
para block is what should happen in that table cell.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#754 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA_a1LANodTybG4PVlj_oAgynBixPM6Rks5qY-f0gaJpZM4JTrr4
.

[AlexDaniel]

Except that now things like C<.race> are not rendered :(

[tbrowder]

On Monday, July 25, 2016, Aleks-Daniel Jakimenko-Aleksejev <
notifications@github.com> wrote:

Except that now things like C<.race> are not rendered :(

Hm, I assume they were before. I think part of the problem is Pod::To::HTML
(and maybe htmlify.p6).

Shall I revert?

[tbrowder]

On Monday, July 25, 2016, Tom Browder tom.browder@gmail.com wrote:

On Monday, July 25, 2016, Aleks-Daniel Jakimenko-Aleksejev <
notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Except that now things like C<.race> are not rendered :(

Hm, I assume they were before. I think part of the problem is
Pod::To::HTML (and maybe htmlify.p6).

Actually, I don't think any pod formatting codes have ever been recognized
in existing tables up til now.

[AlexDaniel]

Shall I revert?

No, it's better than it was.

Still :( though.

[molecules]

Is this better? #758

[tbrowder]

On Mon, Jul 25, 2016 at 11:53 AM, Christopher Bottoms <
notifications@github.com> wrote:

Is this better? #758 #758

​Excellent, Christopher! And good practice for most tables--footnotes for
those interested in the details.

[AlexDaniel]

OK, after #758 it is not broken anymore, so we can close this issue. … however, I'd love to see some changes to pod itself so that there's at least some way to have that kind of stuff in table cells.