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?

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?

I've looked into this a bit, but haven't had time to do anything with it.

My opinion is that the starting point is to add functionality using Oct-Files. The reason is that it is the simplest way to do so in a way that you can share your work with others. That allows you to call into the Octave API and reuse that code. Given the recent work on C++ interoperability, I think this strategy is the clear winner.

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?

With respect to this part of your question, you might want to check out
https://dlang.org/spec/betterc.html

and especially the limitations
https://dlang.org/spec/betterc.html#consequences

It shouldn't take much to do this, but the limitations of betterC are not minor.

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?

I'm a little confused...you mean like embedr [1, 2] and pyd [3], but for Octave and Matlab? The idea would that you could write functions in D and call them in Matlab/Octave, and vice-versa. I suppose that. I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add...

There was an old forum post years ago on the subject [4], but the link to the repository is dead.

[1] https://bitbucket.org/bachmeil/embedr
[2] https://github.com/bdilday/embedr
[3] https://code.dlang.org/packages/pyd
[4] https://forum.dlang.org/thread/op.vhjavyoc3ncmek@enigma.fem.tu-ilmenau.de

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.

- This can be a problem if the project is very active. This issue was noticed by the people who converted DMD compiler from C++ to D and finally a dedicated tool was used, improved until some CI tests passed.

> 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?

- The runtime can be initialized by hand if it's required, see core.runtime.Runtime.initialize()

On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote:
> 
> I suppose that. [snip]

I suppose that would be good.

On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote:
> I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add...

I'm daydreaming of being able to rewrite all of Octave in D. I just was trying to think of where to start.

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?

Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22D+Conversion%22+) helps?
Here -betterC is used.

The frontend was automatically converted to D a few years ago (https://github.com/dlang/dmd/tree/last-cdmd/src/magicport), though magicport was a bit specific to DMD's codebase.

On Tuesday, 10 July 2018 at 20:28:00 UTC, Seb wrote:

>
> Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22D+Conversion%22+) helps?
> Here -betterC is used.

Octave is so far from -betterC, though. It's very C++-heavy, with C++11 features being used since the last couple of years. It's an old codebase that started circa 1992. Just getting it into -betterC territory seems like a very daunting task.

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.