Re: Open Methods: From C++ to D

[Arun Chandrasekaran via Digitalmars-d-announce]

On Tuesday, 29 August 2017 at 12:45:50 UTC, Jean-Louis Leroy 
wrote:

On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:

Nice. This does seem superior to the visitor pattern.


Here is another example - AST traversal: 
https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d


Thanks for this library. Just a suggestion. Would it possible to 
use `@openmethod` instead of `@method`?

Re: D as a Better C

[Parke via Digitalmars-d-announce]

On Tue, Aug 29, 2017 at 7:19 PM, Michael V. Franklin via
Digitalmars-d-announce  wrote:
> For example, the following is the most minimal "Hello World" I can make with
> D that does not require the -betterC switch, and does not use the official D
> runtime.  Instead the runtime features required by this program are
> implemented in object.d.

Thank you for the very helpful example and explanation.

-Parke

Re: D as a Better C

[Michael V. Franklin via Digitalmars-d-announce]

On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:


But my original question was about what you (Kagamin) called
"intermediate D".  I was trying to understand what 
"intermediate D"
is, and whether or not I could use "intermediate D" (whatever 
it is)

to produce small(er) executables.


"Intermediate D" probably refers to not use the -betterC switch, 
not linking in the official druntime, and instead implementing 
the features of D required by your program yourself.


For example, the following is the most minimal "Hello World" I 
can make with D that does not require the -betterC switch, and 
does not use the official D runtime.  Instead the runtime 
features required by this program are implemented in object.d.


object.d

module object;

alias immutable(char)[] string;

struct ModuleInfo { }

class Object { }

class TypeInfo
{
bool equals(in void* p1, in void* p2) const
{
return p1 == p2;
}

int compare(in void* p1, in void* p2) const
{
return _xopCmp(p1, p2);
}
}

class TypeInfo_Class : TypeInfo
{
ubyte[136] ignore;
}

alias TypeInfo_Class ClassInfo;

class TypeInfo_Struct : TypeInfo
{
ubyte[120] ignore;
}

extern (C) Object _d_newclass(const ClassInfo ci)
{
return null;
}

extern(C) void _d_throwc(Object h) { }

class Throwable { }

class Error : Throwable
{
this(string x)
{ }
}

extern(C) void _d_throwdwarf(Throwable o) { }

extern(C) void _d_dso_registry(void* data) { }


// The following code basically replaces the C runtime
//
extern extern(C) int main(int argc, char** argv);

extern(C) void sys_exit(long arg1)
{
asm
{
mov RAX, 60;
mov RDI, arg1;
syscall;
}
}

extern(C) void _start()
{
auto ret = main(0, null);
sys_exit(ret);
}

private alias extern(C) int function(char[][] args) MainFunc;

extern (C) int _d_run_main(int argc, char **argv, MainFunc 
mainFunc)

{
// ignore args for now
return mainFunc(null);
}

main.d
--
module main;

long sys_write(long arg1, in void* arg2, long arg3)
{
long result;

asm
{
mov RAX, 1;
mov RDI, arg1;
mov RSI, arg2;
mov RDX, arg3;
syscall;
}

return result;
}

void write(in string text)
{
sys_write(2, text.ptr, text.length);
}

void main()
{
write("Hello\n");
}

Building and executing
--
On Linux 64-bit compile with:
$ dmd -c -fPIC -release object.d main.d -of=main.o

Link with:
$ ld main.o -o main

Report size:
$ size main
   textdata bss dec hex filename
   10701872   82950 b86 main

Text execution:
$ ./main
Hello

If you link with:
$ ld main.o -o main --gc-sections

You end up with:
$ size main
   textdata bss dec hex filename
9501688   02638 a4e main


This illustration does not require -betterC, but instead requires 
you to implement a "minimal D runtime" specific to your program, 
and the features of D that it employs.  In this illustration that 
"minimal D runtime" is object.d.


As you can see it is not a polished experience and gets much 
worse when you start employing more features of D.  This could be 
improved, and in fact, with GDC you need even less useless 
boilerplate in object.d and may end up with an even smaller 
executable. (Maybe I'll follow up later with GDC illustration.  
Right now I don't have a computer with the latest GDC installed). 
 If you try this experiment with LDC, you may end up with a 
multi-gigabyte file and crash your PC due to 
https://github.com/ldc-developers/ldc/issues/781


Hopefully we can improve the compiler/runtime implementation so 
doing this kind of programming won't require so many useless 
stubs, and users can implement just the features of D that they 
need for their program without having to rely on the on the blunt 
and heavy hand of -betterC.


Mike

Re: D as a Better C

[Adam D. Ruppe via Digitalmars-d-announce]

On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:
The above D code yields 445,187 bytes when compiled with 
-release -betterC.

DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.


-betterC does virtually nothing on that version of dmd...


But my original question was about what you (Kagamin) called
"intermediate D".  I was trying to understand what 
"intermediate D"
is, and whether or not I could use "intermediate D" (whatever 
it is)

to produce small(er) executables.


Regular D with a custom runtime library. You can get as small as 
3 KB on Linux (though that is a super bare bones hello world).


But note that if you are distributing several executables you 
might also just use the shared phobos lib too with 
-defaultlib=libphobos2.so on Linux.

Re: D as a Better C

[Parke via Digitalmars-d-announce]

> On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:
>> When I write "hello world" in C, the executable is 8,519 bytes.
>>  When I write "hello world" in D, the executable is 100 times larger:
>> 865,179 bytes.


On Tue, Aug 29, 2017 at 8:26 AM, Kagamin via Digitalmars-d-announce
 wrote:
> You mean the examples from the blog post
> https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb
> executables?


No, I was talking about the below version of "hello world" that I
compiled several weeks prior to reading the blog post.

import std.stdio;
void main() { writeln("Hello, world!"); }

The above D code yields 865,179 bytes.


Below is the version from the blog post:

import core.stdc.stdio;
extern (C) int main( int argc, char** argv ) {
printf ( "hello world\n" );
return 0;
}

The above D code yields 445,244 bytes when compiled with -release.
The above D code yields 445,187 bytes when compiled with -release -betterC.
DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.

Still 50 times larger than C.  Perhaps it would be smaller with a
newer version of DMD.

But my original question was about what you (Kagamin) called
"intermediate D".  I was trying to understand what "intermediate D"
is, and whether or not I could use "intermediate D" (whatever it is)
to produce small(er) executables.

-Parke

Re: Beta 2.076.0

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/18/2017 02:58 PM, Martin Nowak wrote:
> First beta for the 2.076.0 release.
> 
Release Candidate out now!

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.076.0.html


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlml3gcACgkQsnOBFhK7
GTm9yg/+JiF+F12kZKNuE0JB6i8DXSbI5/itvG1ja9YFwn6BppjNH6dRtR/5wVnJ
Bh8Hz629Q7XoAysAyMcCEdKEKZ1VcHcKs5169AjENpMsvRxzEjEL0I3lXIeU5CFh
xqSX+6ucEEh7ZfNn7f7AfZW2trYc76rc3Udyr00y7bmrJKcgTUoqZcmclclP+UUJ
mKdk3+g4lxYt7To9M1CAqooBN2bEIosBF/mGjrX7PoQQq25exFfA4sg0rIIb5dS5
U1LnF9Jt3vj9p3R5fGNhci5XzHvjAxfssPMB6i040U0pfmaywWY348QKOzMXlaiw
5sFc0CSf+0R88eXf2Q2JcfXuJ7RC5hhCiDYKvaFjLOacRHnlAK78RPs/Og5DDWis
el6D83fOnADUqMWRFEe9+JX1Y0kD/2F1f8bHhF5UobTngSWCurRRbUwOSZgNr8Xh
nrh78PNAn15/bRftXtoiD9tS/B5TLZpNVr2NwpaPv/Wl/90BQSyGJB8HmtScFxHp
Kys6MbFQz+0TLyk9Qe7tX0libOB0Npegb1m5dwJGTDTg8pQPo2KRYnks8K/UZEY7
Ew9up2x2n2FId7vC/qsMKU4ItKfbKg6mNo6KA0wrVk3pehA7AfzqyMJ0Txhe/cKJ
bw2T1jRkF+q3R19y9tbIeZM8qHzraLmhVXETYiZ6HCXBIGWIj9A=
=lBFr
-END PGP SIGNATURE-

Re: D as a Better C

[Kagamin via Digitalmars-d-announce]

On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:

When I write "hello world" in C, the executable is 8,519 bytes.
 When I write "hello world" in D, the executable is 100 times 
larger: 865,179 bytes.


You mean the examples from the blog post 
https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb 
executables?

Re: LDC 1.4.0-beta1

[Nicholas Wilson via Digitalmars-d-announce]

On Tuesday, 29 August 2017 at 13:11:44 UTC, kinke wrote:
On Tuesday, 29 August 2017 at 12:46:16 UTC, Andrea Fontana 
wrote:

On Saturday, 26 August 2017 at 22:35:11 UTC, kinke wrote:
* Shipping with ldc-build-runtime, a small D tool to easily 
(cross-)compile the runtime libraries yourself.


Have anyone ever tried to compile a linux version of ldc that 
generates windows executables?


Andrea


Yep, I even mentioned it prominently in the 1.3 release log. 
See 
https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412. That was before ldc-build-runtime though; I simply used druntime/Phobos from the prebuilt Win64 package.


Ooh, sweet! I might try this if I can't get LDC to build on 
windows and just build the libs from my mac instead.

Re: LDC 1.4.0-beta1

[Andrea Fontana via Digitalmars-d-announce]

On Tuesday, 29 August 2017 at 13:11:44 UTC, kinke wrote:
On Tuesday, 29 August 2017 at 12:46:16 UTC, Andrea Fontana 
wrote:

On Saturday, 26 August 2017 at 22:35:11 UTC, kinke wrote:
* Shipping with ldc-build-runtime, a small D tool to easily 
(cross-)compile the runtime libraries yourself.


Have anyone ever tried to compile a linux version of ldc that 
generates windows executables?


Andrea


Yep, I even mentioned it prominently in the 1.3 release log. 
See 
https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412. That was before ldc-build-runtime though; I simply used druntime/Phobos from the prebuilt Win64 package.


Is there also a wiki page about this?

Re: LDC 1.4.0-beta1

[kinke via Digitalmars-d-announce]

On Tuesday, 29 August 2017 at 12:46:16 UTC, Andrea Fontana wrote:

On Saturday, 26 August 2017 at 22:35:11 UTC, kinke wrote:
* Shipping with ldc-build-runtime, a small D tool to easily 
(cross-)compile the runtime libraries yourself.


Have anyone ever tried to compile a linux version of ldc that 
generates windows executables?


Andrea


Yep, I even mentioned it prominently in the 1.3 release log. See 
https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412. That was before ldc-build-runtime though; I simply used druntime/Phobos from the prebuilt Win64 package.

Re: LDC 1.4.0-beta1

[Andrea Fontana via Digitalmars-d-announce]

On Saturday, 26 August 2017 at 22:35:11 UTC, kinke wrote:
* Shipping with ldc-build-runtime, a small D tool to easily 
(cross-)compile the runtime libraries yourself.


Have anyone ever tried to compile a linux version of ldc that 
generates windows executables?


Andrea

Re: Open Methods: From C++ to D

[Jean-Louis Leroy via Digitalmars-d-announce]

On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:

Nice. This does seem superior to the visitor pattern.


Here is another example - AST traversal: 
https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d

Re: Open Methods: From C++ to D

[Mark via Digitalmars-d-announce]

On Monday, 28 August 2017 at 12:19:26 UTC, Mike Parker wrote:
Jean-Louis Leroy posted about his open methods library here in 
the forums some time ago. Now, he's written a blog post that 
explains what open methods are, and describes the D 
implementation and how it compares to his C++ library.


The blog:
https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

Reddit:
https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/


Nice. This does seem superior to the visitor pattern.