On Fri, 2017-06-02 at 20:47 +0000, Mike B Johnson via Digitalmars-d- learn wrote:
> […]
> 
> Would you mind, when you get some time, to write up a more detailed analysis of the problems you had to overcome to get it to work? Possibly we could get some type of library solution that just "works" with very little change and restriction?
> 
> After all, dll's effectively already solve the problem, in some sense... except they are generally not meant to be reloaded on demand. Solving the issues that reloading causes, I think, would be the bulk of the problem?

And there are always magazines/journals such as Overload and CVu [1] which are places to publish articles that are more than just Web ephemera.


[1] https://accu.org/index.php/journal

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 3 June 2017 at 00:02:54 UTC, Lewis wrote:
> On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:
>> [...]
>
> For sure. I actually want to post the source code at some point, but the changes I made are very much set up specifically for this project. I'll sift through at some point and see if I can gather together something worth posting.
>
> [...]

Thanks. Maybe some of this could be overcome by a design pattern that removes them from being an issue(e.g., script can not use GC... only to demonstrate that if that were the case, then you wouldn't have to worry about GC issues ;)?

I imagine that if "dll"'s were used that one would have all the power to debug and develop them as normal d code, which is nice and doesn't require a "script editor and debugger".

On 03/06/2017 10:03 AM, Mike B Johnson wrote:
> On Saturday, 3 June 2017 at 00:02:54 UTC, Lewis wrote:
>> On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:
>>> [...]
>>
>> For sure. I actually want to post the source code at some point, but the changes I made are very much set up specifically for this project. I'll sift through at some point and see if I can gather together something worth posting.
>>
>> [...]
> 
> Thanks. Maybe some of this could be overcome by a design pattern that removes them from being an issue(e.g., script can not use GC... only to demonstrate that if that were the case, then you wouldn't have to worry about GC issues ;)?
> 
> I imagine that if "dll"'s were used that one would have all the power to debug and develop them as normal d code, which is nice and doesn't require a "script editor and debugger".

A lot of this can be done by simply implementing shared libraries fully on Windows. There is a reason why TypeInfo doesn't cross the dll boundary right now. Sadly it isn't a high priority (and it really really needs to be "just done already"). Its fine for Linux.

On Saturday, 3 June 2017 at 09:28:03 UTC, rikki cattermole wrote:
> A lot of this can be done by simply implementing shared libraries fully on Windows. There is a reason why TypeInfo doesn't cross the dll boundary right now. Sadly it isn't a high priority (and it really really needs to be "just done already"). Its fine for Linux.

Is the D DLL situation different between Windows and Linux right now? If so, in what ways? I'm curious, I'm not set up for development on Linux currently so I wouldn't be up-to-date on these things.

On 03/06/2017 4:43 PM, Lewis wrote:
> On Saturday, 3 June 2017 at 09:28:03 UTC, rikki cattermole wrote:
>> A lot of this can be done by simply implementing shared libraries fully on Windows. There is a reason why TypeInfo doesn't cross the dll boundary right now. Sadly it isn't a high priority (and it really really needs to be "just done already"). Its fine for Linux.
> 
> Is the D DLL situation different between Windows and Linux right now? If so, in what ways? I'm curious, I'm not set up for development on Linux currently so I wouldn't be up-to-date on these things.

It is yes, all I know off the top of my head is that Windows is definitely broken and Linux should just work out of the box.

On Saturday, 3 June 2017 at 05:04:24 UTC, Russel Winder wrote:
> Not enough is made of rdmd. rdmd needs to be separated from dmd so it works with gdc and ldc2.

rdmd has always worked with them, at least with their gdmd and ldmd wrappers

https://github.com/dlang/tools/blob/master/rdmd.d#L46

On Sat, 2017-06-03 at 17:08 +0000, Adam D. Ruppe via Digitalmars-d- learn wrote:
> On Saturday, 3 June 2017 at 05:04:24 UTC, Russel Winder wrote:
> > Not enough is made of rdmd. rdmd needs to be separated from dmd so it works with gdc and ldc2.
> 
> rdmd has always worked with them, at least with their gdmd and ldmd wrappers
> 
> https://github.com/dlang/tools/blob/master/rdmd.d#L46
> 

So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:
> So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers?

it is... the link above is all there is to it, you simply compile it. The docs also call it a download: http://dlang.org/rdmd.html

dmd just happens to bundle it. The others prolly should too.

On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote:
> On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:
>> So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers?
>
> it is... the link above is all there is to it, you simply compile it. The docs also call it a download: http://dlang.org/rdmd.html
>
> dmd just happens to bundle it. The others prolly should too.

Ldc should have it in the next release, except on Windows:

https://github.com/ldc-developers/ldc/issues/548#issuecomment-306073946