Am Sat, 14 Dec 2013 21:11:46 +0100
schrieb "hoya" <sighoya@gmail.com>:

> On Saturday, 14 December 2013 at 17:47:34 UTC, Marco Leise wrote:
> > Am Sat, 14 Dec 2013 14:59:42 +0100
> > schrieb "hoya" <sighoya@gmail.com>:
> >
> >> On Saturday, 14 December 2013 at 13:44:01 UTC, Marco Leise wrote:
> >> 
> >> > You can load libraries at runtime like OpenGL or a database driver. This applies to all C and D libraries as well as C++ libraries to some extent.
> >> >
> >> Can you give me an example how to do this?
> >
> > Hmm, there are two options when it comes to dynamic linking.
> >
> > You can directly refer to the functions you use from some library. An example is std.net.curl in Phobos. You compile your program with "dmd -L-lcurl <source>" to link to the curl library which is written in C and common on Linux systems. This is the simple case where you don't need to write any extra code.
> >
> > If you want to load a plugin at runtime or OpenGL (which is a
> > different library for each graphics card vendor) you will need
> > to use the dynamic linker (libdl.so) which handles this case:
> > "dmd -L-ldl <source>" and then use "dlopen" and "dlsym" in
> > your program to find the addresses of functions. Derelict 3 is
> > a good example of loading libraries at runtime this way:
> > https://github.com/aldacron/Derelict3
> > It is a wrapper/binding collection for many multimedia/game
> > related libraries and you can reuse its derelict.util module
> > to load your own libraries at runtime.
> >
> > Which case are you interested in?
> >
> The Latter
> > This can be done with dmd as
> > well, but in both cases it is crutch to bring eval()-like
> > functionality to a statically compiled language. :)
> Hmm. An eval() method is good, if writing something like a Drepl.
> I've heard from someone that other people have tried some work on
> it.
> Or good case, if you can use a dynamic mixin(). When read a
> string from input, then it is possible to create a structure like
> struct, class and so on. With dlopen() you need at least a
> library file, where all your code is written in, as I thin
> correctly. But with a dynamic mixin() you have the ability, to
> add structures in-memory. So this is more efficient.

A simple REPL that doesn't remember any previous state is
easily written today. It becomes difficult when you want to
keep your state from command to command or try to delete
previous definitions.
For what you want there would have to be a JIT compiler in
every D program in the first place. Interpreted languages and
JIT compiled languages have an advantage here.
eval() is more efficient in the way that you don't need to go
though an external file and have the dynamic linker load it,
yes. But even if a real eval() existed, there is no point in
adding structs to the program that way, since the rest of the
code isn't prepared to accept them. Sub-classes would work.
I would look into using an interpreted or JIT compiled
language from within D for the parts of your code that need
to be dynamic. Take like LuaD for example:
https://github.com/JakobOvrum/LuaD
Python or JavaScript bindings would do as well.

-- 
Marco

On Saturday, 14 December 2013 at 23:36:12 UTC, Marco Leise wrote:
> Am Sat, 14 Dec 2013 21:11:46 +0100
> schrieb "hoya" <sighoya@gmail.com>:
>
>> On Saturday, 14 December 2013 at 17:47:34 UTC, Marco Leise wrote:
>> > Am Sat, 14 Dec 2013 14:59:42 +0100
>> > schrieb "hoya" <sighoya@gmail.com>:
>> >
>> >> On Saturday, 14 December 2013 at 13:44:01 UTC, Marco Leise wrote:
>> >> 
>> >> > You can load libraries at runtime like OpenGL or a database
>> >> > driver. This applies to all C and D libraries as well as C++
>> >> > libraries to some extent.
>> >> >
>> >> Can you give me an example how to do this?
>> >
>> > Hmm, there are two options when it comes to dynamic linking.
>> >
>> > You can directly refer to the functions you use from some
>> > library. An example is std.net.curl in Phobos. You compile
>> > your program with "dmd -L-lcurl <source>" to link to the curl
>> > library which is written in C and common on Linux systems.
>> > This is the simple case where you don't need to write any
>> > extra code.
>> >
>> > If you want to load a plugin at runtime or OpenGL (which is a
>> > different library for each graphics card vendor) you will need
>> > to use the dynamic linker (libdl.so) which handles this case:
>> > "dmd -L-ldl <source>" and then use "dlopen" and "dlsym" in
>> > your program to find the addresses of functions. Derelict 3 is
>> > a good example of loading libraries at runtime this way:
>> > https://github.com/aldacron/Derelict3
>> > It is a wrapper/binding collection for many multimedia/game
>> > related libraries and you can reuse its derelict.util module
>> > to load your own libraries at runtime.
>> >
>> > Which case are you interested in?
>> >
>> The Latter
>> > This can be done with dmd as
>> > well, but in both cases it is crutch to bring eval()-like
>> > functionality to a statically compiled language. :)
>> Hmm. An eval() method is good, if writing something like a Drepl. I've heard from someone that other people have tried some work on it.
>> Or good case, if you can use a dynamic mixin(). When read a string from input, then it is possible to create a structure like struct, class and so on. With dlopen() you need at least a library file, where all your code is written in, as I thin correctly. But with a dynamic mixin() you have the ability, to add structures in-memory. So this is more efficient.
>
> A simple REPL that doesn't remember any previous state is
> easily written today. It becomes difficult when you want to
> keep your state from command to command or try to delete
> previous definitions.
> For what you want there would have to be a JIT compiler in
> every D program in the first place. Interpreted languages and
> JIT compiled languages have an advantage here.
> eval() is more efficient in the way that you don't need to go
> though an external file and have the dynamic linker load it,
> yes. But even if a real eval() existed, there is no point in
> adding structs to the program that way, since the rest of the
> code isn't prepared to accept them. Sub-classes would work.
> I would look into using an interpreted or JIT compiled
> language from within D for the parts of your code that need
> to be dynamic. Take like LuaD for example:
> https://github.com/JakobOvrum/LuaD
> Python or JavaScript bindings would do as well.
I will keep this in mind, thanks.
Thanks all for helping!