Skip to content

Remove the assert->writeln pipeline in favor of the DDoc wrapper#2069

Merged
dlang-bot merged 13 commits into
dlang:masterfrom
wilzbach:writeln-dynamic
Feb 19, 2018
Merged

Remove the assert->writeln pipeline in favor of the DDoc wrapper#2069
dlang-bot merged 13 commits into
dlang:masterfrom
wilzbach:writeln-dynamic

Conversation

@wilzbach

@wilzbach wilzbach commented Jan 9, 2018

Copy link
Copy Markdown
Contributor

Idea: use a custom Ddoc wrapper to pre-process the source files and avoid the
need for creating a temporary directory with the processed sources.

@dlang-bot

Copy link
Copy Markdown

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

@CyberShadow

Copy link
Copy Markdown
Member

Cool, thanks!

@wilzbach

wilzbach commented Jan 9, 2018

Copy link
Copy Markdown
Contributor Author

BTW any idea how I can deal with the conflicts without creating any files?

> cd ~/dlang/phobos
> cat std/algorithm/package.d | dmd -c -o- -D -
std/algorithm/comparison.d(59): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d
std/algorithm/iteration.d(67): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d
std/algorithm/mutation.d(78): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d
std/algorithm/searching.d(106): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d
std/algorithm/setops.d(48): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d
std/algorithm/sorting.d(76): Error: package name 'std.algorithm' conflicts with usage as a module name in file __stdin.d

@quickfur

quickfur commented Jan 9, 2018

Copy link
Copy Markdown
Member

Oh man... looks like the hack I used to make stdin work with dmd has backfired. :-( Will have to look into this deeper at some point.

@wilzbach

Copy link
Copy Markdown
Contributor Author

Started to move ahead with this transition and moved the second commit to #2072

@wilzbach wilzbach removed the WIP label Feb 4, 2018
@wilzbach wilzbach changed the title [WIP] Remove the assert->writeln pipeline in favor of the DDoc wrapper Remove the assert->writeln pipeline in favor of the DDoc wrapper Feb 4, 2018
@wilzbach
wilzbach force-pushed the writeln-dynamic branch 3 times, most recently from 5078a84 to 3c031c1 Compare February 4, 2018 22:02
@wilzbach

wilzbach commented Feb 4, 2018

Copy link
Copy Markdown
Contributor Author

@CyberShadow I think this is finally ready :)

Note: it has the downsides

  • that package modules don't use the assert/rewrite pipeline for now
  • temporary files are used/created for now
  • ddox doesn't use this assert/rewrite pipeline either

However, the assert/writeln rewrite is imho just a nice to have - it's not a huge deal if it's not there for a few modules and on the upside:

  • we can now easily enable it for druntime/dmd
  • we get rid of -80 lines
  • it makes disabling the assert/rewrite pipeline a lot easier (could be a simple flag for the CLI preprocessor)
  • we get rid of the annoying need to auto-clone phobos

Especially the last bit would be nice to finally have - it would make #2162 a bit easier.

Once this is in, we can always figure out how to close the remaining problems, but I think we need to have a start and common base somewhere.

@CyberShadow

Copy link
Copy Markdown
Member

A bit sad that the DDox examples will regress to standard asserts, but I guess that could be fixable in DDox itself, right?

@CyberShadow CyberShadow left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You still have a reference to $(ASSERT_WRITELN_BIN), that's causing the test target to fail:

test: $(ASSERT_WRITELN_BIN)_test test_dspec test/next_version.sh all

Comment thread posix.mak
# before actually running Ddoc.
# Currently this is used for:
# - TOC
# - assert -> writeln magic

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the two lists of the program's tasks/capabilities are redundant (and one is more complete than the other).

👍 on more docs though.

Comment thread posix.mak Outdated
# - This transforms assert(a == b) to writeln(a); // b
# - It creates a copy of Phobos to apply the transformations
# - All "d" files are piped through the transformator,
# other needed files (e.g. posix.mak) get copied over

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(the second list is here)

Comment thread ddoc/dub.sdl Outdated
@@ -0,0 +1,4 @@
name "ddoc_preprocessor"
description "Preprocessos source code before running Ddoc over it"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Preprocesses" :)

Comment thread ddoc/dub.sdl Outdated
name "ddoc_preprocessor"
description "Preprocessos source code before running Ddoc over it"
dependency "libdparse" version="0.7.2-alpha.4"
targetType "executable"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have do use Dub here?

Unless you plan to add dependencies from code.dlang.org, rdmd should suffice.

I don't object to using Dub, just thinking back to all the times it gave us trouble, and don't want to add to that pile.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, but it doesn't change the status quo. The assert_writeln_magic script used dub too.

Unless you plan to add dependencies from code.dlang.org

Yeah, we need libdparse. I'm no huge fan of dub either, either because it seems like we/I are the ones who do all the dog-fooding of it to make it and the registry mature.
Unfortunately, that's also a reason to keep using dub here (instead of doing git clones).

@wilzbach
wilzbach force-pushed the writeln-dynamic branch 2 times, most recently from 795b293 to 93133cf Compare February 5, 2018 00:08
@wilzbach

wilzbach commented Feb 5, 2018

Copy link
Copy Markdown
Contributor Author

A bit sad that the DDox examples will regress to standard asserts, but I guess that could be fixable in DDox itself, right?

Okay, now I did it in this PR ;-)
I had to copy over the ddox main executable even though only a small patch is required - see the last commit: 93133cf

@CyberShadow

Copy link
Copy Markdown
Member

Failing with make: dub: Command not found

@wilzbach Not really related to this PR, but it looks like DAutoTest is redoing a lot of work for the test target. This is probably contributing a lot to the long build times. E.g. open a log and search for dautotest: Running tests - there's a lot of stuff past that point that seems redundant.

@wilzbach
wilzbach force-pushed the writeln-dynamic branch 2 times, most recently from b8aa500 to e72e872 Compare February 5, 2018 00:35
@wilzbach

wilzbach commented Feb 5, 2018

Copy link
Copy Markdown
Contributor Author

there's a lot of stuff past that point that seems redundant.

Good catch - let's try #2170 for a start

@wilzbach

wilzbach commented Feb 8, 2018

Copy link
Copy Markdown
Contributor Author

(rebased)

Are the changes to ddox.main upstreamable? This might not be a future-proof approach if ddox gets updated.

Not sure, while it's essentially a two-line change, ddox isn't very customizable yet.
I will try to get them upstream, but that might take weeks or months.

@wilzbach

wilzbach commented Feb 9, 2018

Copy link
Copy Markdown
Contributor Author

Rebased again - it's getting a bit tedious to maintain/rebase this. What's blocking for this?

@CyberShadow

Copy link
Copy Markdown
Member

I've been a little hesitant because forking DDox seems to be a liability in the long-term.

Would be good to see some initial effort of upstreaming the changes before this is merged.

@wilzbach

Copy link
Copy Markdown
Contributor Author

https://issues.dlang.org/show_bug.cgi?id=18442 (linking to unittests) would be easy to implement with the changes of this PR.

@wilzbach

Copy link
Copy Markdown
Contributor Author

I've been a little hesitant because forking DDox seems to be a liability in the long-term.
Would be good to see some initial effort of upstreaming the changes before this is merged.

Okay, I reduced the copy of ddox.main to the currently required minimum and opened a PR with the change that would be required to remove "the fork":

dlang/ddox#199

Good enough?

@CyberShadow CyberShadow left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Hopefully this will go a long way.

@wilzbach
wilzbach deleted the writeln-dynamic branch February 19, 2018 07:05
MoonlightSentinel added a commit to MoonlightSentinel/dlang.org that referenced this pull request Feb 12, 2022
The first process was started by `pipeProcess` but never interacted with,
not even calling `wait` before starting the next instance - with exact
same arguments!

Seems like this line wasn't deleted in dlang#2069 which
introduced `execute` and removed the other code interacting with the
piped process.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants