Jump to page: 1 2 3
Thread overview
Is it feasible to slowly rewrite a C++ codebase in D?
Jun 20
bachmeier
Jun 20
bachmeier
Jun 20
jmh530
Jun 20
jmh530
Jun 20
user1234
Jul 10
Seb
Jul 11
Dukc
Jul 12
Seb
Jul 13
Dukc
Jul 16
Dukc
Jul 16
Seb
Jul 16
Timoses
Jul 16
Seb
Jul 13
Dukc
Jul 16
bachmeier
Jul 17
drug
Jul 17
bachmeier
Jul 17
bachmeier
Jul 17
jmh530
Jul 18
bachmeier
Jul 20
bachmeier
Jul 20
jmh530
June 20
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?
June 20
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.
June 20
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.
June 20
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
June 20
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()


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

I suppose that would be good.
July 10
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.
July 10
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.
July 11
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.
July 11
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.
« First   ‹ Prev
1 2 3