On Saturday, 17 February 2018 at 21:23:25 UTC, Manu wrote:
> Wait, what? You asked if people used them, found that they did, then pulled
> the plug anyway? O_o
> Try running WINE on the build machine... it's trivial to setup.

Note the 2-year gap. I guess this decision is based off low interest shown during this gap to actually maintain the tools.

On 18 February 2018 at 05:26, Cym13 via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Saturday, 17 February 2018 at 21:23:25 UTC, Manu wrote:
>
>> Wait, what? You asked if people used them, found that they did, then
>> pulled
>> the plug anyway? O_o
>> Try running WINE on the build machine... it's trivial to setup.
>>
>
> Note the 2-year gap. I guess this decision is based off low interest shown during this gap to actually maintain the tools.
>

Heh, I didn't notice anything but the timestamp of the most recent post.

On 18 February 2018 at 12:28, Martin Nowak <code@dawg.eu> wrote:

> It should be equally trivial to setup an appveyor.yml task for dlang.org
> that builds
> a chm file for any git tag.
>

That's an even better idea! I expect there is scripting in place to build
the doc, since some machinery must have been working for the past decade or
2?
Is it just a matter of executing that script on a windows machine?
Synchronisation sounds annoying though, how do you aggregate an appveyor
output into the main release bundle? Maybe combining different build
machines is harder?

On 02/18/2018 02:05 AM, Walter Bright wrote:
> On 2/17/2018 7:04 AM, Martin Nowak wrote:
>> Let's pull the plug, I think everybody agrees that we have more
>> important issues than maintaining d.chm and dman (which hasn't been
>> shipped since 2.076 anyhow).
>> Consider both tools as offered for adoption (as an external service or
>> download).
>>
>> https://github.com/dlang/installer/pull/298
>>
> 
> I find dman very useful, as I'm a command line sorta guy. In fact, I wrote it because it's a major convenience for me.

I know, but I think you are one of the very users though.

On my shell it's simple to add an alias that would invoke https://duckduckgo.com/?q=popFrontN+site%3Adlang.org%2Flibrary. Personally I do have a browser shortcut 'd' for my Brower's omnibox, so I can just type 'd popFrontN' in FireFox to find docs.

The essence here is that while dman might be useful, it's foundation is
very complex and fragile, using ddoc JSON macros :o
(https://github.com/dlang/dlang.org/blob/cb44110267d0b5d2e139909c47fa00924ac1cb24/chm-nav.dd)
and a self-written html/link processor to gather tags.
Sure Vladimir is great at maintaining tools and very responsive, but
still any issue with this tool blocks our releases and wastes my time.

Same as for d.chm, I'd favor if that tool would be build and distributed separately from our dmd releases, and if the actual users would maintain it. This could be setup on Travis-CI using ldc to cross-compile for all target platforms or so.

-Martin

On 02/17/2018 10:19 PM, Manu wrote:
> I like the CHM docs.
> I have encountered the same maintenance problem before, where build infra
> is linux based, and the CHM docs need a windows machine to build... I
> solved this problem by building the CHM via WINE ;)
> Maybe this is a possible solution?

Yes might be an option, but I have little experience with Wine, and adding more complexity to an already complex tool seems problematic. We obviously do build releases on Windows (VirtualBox) and also have Windows CIs, but Vladimir's doc tester is linux-only atm.

I mainly don't want to spent more resources to work on this, hence it's
offered for adoption. You might want to collaborate with Vladimir to
integrate this with dlang.org's appveyor.
It can easily test every build and upload artifacts for git tags.

-Martin

On Sunday, 18 February 2018 at 21:31:48 UTC, Martin Nowak wrote:
> The essence here is that while dman might be useful, it's foundation is
> very complex and fragile, using ddoc JSON macros :o
> (https://github.com/dlang/dlang.org/blob/cb44110267d0b5d2e139909c47fa00924ac1cb24/chm-nav.dd)

Minor correction - the JSON macros are not needed for dman. They are needed for CHM navigation.

The core problem is that the dlang.org navigation (top menu) does not exist in any semantic machine-readable format other than DDoc macros. Previous chmgen implementations parsed HTML to understand the site structure, but that became no longer possible after the last dlang.org website overhaul.

There is no particular reason to use JSON here. I chose JSON because I noticed that it seemed possible to generate (almost-correct) JSON from the navigation DDoc files, so I took the opportunity.

I think we could reuse this system to build a sitemap that is more than a flat list of links.

On Sunday, 18 February 2018 at 21:37:01 UTC, Martin Nowak wrote:
> Yes might be an option, but I have little experience with Wine, and adding more complexity to an already complex tool seems problematic. We obviously do build releases on Windows (VirtualBox) and also have Windows CIs, but Vladimir's doc tester is linux-only atm.
>
> I mainly don't want to spent more resources to work on this, hence it's
> offered for adoption. You might want to collaborate with Vladimir to
> integrate this with dlang.org's appveyor.
> It can easily test every build and upload artifacts for git tags.

As far as I've seen, so far all failures have been in chmgen or some of its inputs or dependencies. I think that once chmgen itself is tested by CI, there should no longer be any blocking problems caused by building the CHM file itself.

https://github.com/dlang/dlang.org/pull/2213 is green and ready to merge, by the way.

El 17/02/18 a les 22:19, Manu via Digitalmars-d ha escrit:
> I like the CHM docs.
> I have encountered the same maintenance problem before, where build infra is linux based, and the CHM docs need a windows machine to build... I solved this problem by building the CHM via WINE ;)
> Maybe this is a possible solution?

I build a CHM doc file for every dmd release, available on d-apt <http://d-apt.sourceforge.net/>, and built on Linux :-)

On Sunday, 18 February 2018 at 21:44:54 UTC, Jordi Sayol wrote:
> El 17/02/18 a les 22:19, Manu via Digitalmars-d ha escrit:
>> I like the CHM docs.
>> I have encountered the same maintenance problem before, where build infra is linux based, and the CHM docs need a windows machine to build... I solved this problem by building the CHM via WINE ;)
>> Maybe this is a possible solution?
>
> I build a CHM doc file for every dmd release, available on d-apt <http://d-apt.sourceforge.net/>, and built on Linux :-)

Downloaded... shows the index (in the left window) but doesn't show any content (in the right window)

On Thursday, 16 June 2016 at 02:32:05 UTC, Jack Stouffer wrote:
> On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote:
>> So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release?
>
> For offline browsing, Windows and Linux users can use Zeal [1] which is FOSS, and macOS users can use Dash[2], which is free as in beer. Both of which can use this D docset [3].
>
> So no, there's no reason to maintain the chm docs.
>
> [1] https://zealdocs.org/
> [2] https://kapeli.com/dash
> [3] https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme

thanks... great community... everyday something new to learn... even in 2+ years old posts ;)