On Wednesday, 11 July 2018 at 20:38:13 UTC, Dukc wrote:
> On Wednesday, 11 July 2018 at 19:41:37 UTC, Jordi Gutiérrez Hermoso wrote:
>> Just getting it into -betterC territory seems like a very daunting task.
>
> You do not need -betterC anymore. At least the LDC frontend will only add linking hooks for what you use, -betterC or no. No need build a stub runtime anymore or give a switch to the compiler to not use the default one.
>
> I know because I compile to JavaScript: first to LLVM bitcode, then manual link (with llvm-link), then to JavaScript using Emscripten. I only have to compile those parts of DRuntime and Phobos I use. Its unlikely I could even have a stub runtime to work, so this is the only reason I can use D in my web page to any real degree.

Also since 2.079 the GC (and many parts of Phobos) get lazily initialized, so while I think there are still some features that might require initialization, it might also be feasible to simply use normal D.

Have you already tried this?

On Thursday, 12 July 2018 at 15:12:51 UTC, Seb wrote:
> it might also be feasible to simply use normal D.
>
> Have you already tried this?

There's no strict distinction between using D normally and in systems programming fashion for me, because my main function isn't written in D.

But in practice it's systems-style code. I mostly use stdc suff which can conveniently link into libraries coming with Emscripten, and std.range and std.algorithm, which do not require instantiations. There are a few instantiated thing from DRuntime and Phobos too, at least slice copying and stuff from std.random. I do not use the GC, nor anything else which has required to call a global initializator.

I know about Vladimir's d-scripten tools library which would help, but it's based on Alawains library copyleft library, which makes also Vladimir's work copyleft, so I won't use it.

On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote:
> Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct?

No. Some initialization is required if you use the GC, as I understand it. But there's no rule it has to be done in a D main function, you can initialize it from anywhere you like.

And if you avoid using stuff that requires the runtime (I'm not sure what it constitutes in addition to GC. Perhaps classes, perhaps typeid, perhaps static constructors and destructors) you do not need to initialize it. -betterC style stuff can be done without it, and as I said it does not need the -betterC switch anymore, at least in LDC.

On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote:
> I'm specifically thinking of the GNU Octave codebase:
>
> http://hg.savannah.gnu.org/hgweb/octave/file/@
>
> It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere.
>
> Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct?
>
> Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification.
>
> What are your ideas?

If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header.  If you encounter a bug, please file an issue and in time we will fix it.

Does not yet work for C++ except in some cases.

https://github.com/atilaneves/dpp

On Friday, 13 July 2018 at 07:51:51 UTC, Dukc wrote:
> I know about Vladimir's d-scripten tools library which would help, but it's based on Alawains library copyleft library, which makes also Vladimir's work copyleft, so I won't use it.

Hmm, I wasn't aware of this. I wonder if the decision to make the redistributable parts of dscripten was intentional (maybe the intention was to apply the license only to the scripts which build the toolchain).

I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else.

On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote:
> I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else.

Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you!

On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote:
> On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote:
>> I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else.
>
> Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you!

https://github.com/Ace17/dscriptenQ/issues/4

On Monday, 16 July 2018 at 11:31:32 UTC, Seb wrote:
> On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote:
>> On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote:
>>> I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else.
>>
>> Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you!
>
> https://github.com/Ace17/dscriptenQ/issues/4

Superfluous Q attack.

Working link: https://github.com/Ace17/dscripten/issues/4

On Monday, 16 July 2018 at 13:15:56 UTC, Timoses wrote:
> On Monday, 16 July 2018 at 11:31:32 UTC, Seb wrote:
>> On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote:
>>> On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote:
>>>> I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else.
>>>
>>> Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you!
>>
>> https://github.com/Ace17/dscriptenQ/issues/4
>
> Superfluous Q attack.
>
> Working link: https://github.com/Ace17/dscripten/issues/4

Sorry for the typo (not sure how that happened) and thanks for correcting!

On Friday, 13 July 2018 at 19:53:45 UTC, Laeeth Isharc wrote:
> On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote:

>> What are your ideas?
>
> If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header.  If you encounter a bug, please file an issue and in time we will fix it.
>
> Does not yet work for C++ except in some cases.
>
> https://github.com/atilaneves/dpp

I would like to give this a try, but I don't see any instructions for installation on the Github page. I tried dub build dpp, but I got a bunch of error messages.