August 31, 2013
On 8/31/2013 4:24 AM, Jacob Carlborg wrote:
> On 2013-08-30 21:50, Walter Bright wrote:
>
>> I think it's a good idea.
>>
>> The only further enhancement I really want to get in this release is DLL
>> support for Linux.
>
> Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have
> already shipped Phobos as a DLL.
>

I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.
August 31, 2013
On 2013-08-31 20:10, Walter Bright wrote:

> I mean that from a C or D program, being able to dynamically load and
> unload DLLs at runtime.

I see.

-- 
/Jacob Carlborg
August 31, 2013
On Sat, Aug 31, 2013 at 11:10:54AM -0700, Walter Bright wrote:
> On 8/31/2013 4:24 AM, Jacob Carlborg wrote:
> >On 2013-08-30 21:50, Walter Bright wrote:
> >
> >>I think it's a good idea.
> >>
> >>The only further enhancement I really want to get in this release is DLL support for Linux.
> >
> >Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL.
> >
> 
> I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.

Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work.


T

-- 
Many open minds should be closed for repairs. -- K5 user
August 31, 2013
On 8/31/2013 1:00 PM, H. S. Teoh wrote:
> Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
> *very* nice, if it can be made to work.


It certainly can be made to work. Martin Nowak is close to getting it done.
August 31, 2013
On Sat, Aug 31, 2013 at 01:27:09PM -0700, Walter Bright wrote:
> On 8/31/2013 1:00 PM, H. S. Teoh wrote:
> >Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work.
> 
> 
> It certainly can be made to work. Martin Nowak is close to getting it done.

Excellent! I presume it will be type-safe and support all the usual D idioms? (I.e., none of that ugly mess with dlsym and C++, where casting void* returned by dlsym() to a func ptr is undefined behaviour according to the C++ spec).


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL
September 01, 2013
On 2013-08-31 23:42, H. S. Teoh wrote:

> Excellent! I presume it will be type-safe and support all the usual D
> idioms? (I.e., none of that ugly mess with dlsym and C++, where casting
> void* returned by dlsym() to a func ptr is undefined behaviour according
> to the C++ spec).

It looks like it only contains functions for loading and unloading DLL's. No functions for handling symbols.

https://github.com/D-Programming-Language/druntime/pull/593

-- 
/Jacob Carlborg
September 01, 2013
On Saturday, 31 August 2013 at 21:44:24 UTC, H. S. Teoh wrote:
> Excellent! I presume it will be type-safe and support all the usual D
> idioms? (I.e., none of that ugly mess with dlsym and C++, where casting
> void* returned by dlsym() to a func ptr is undefined behaviour according
> to the C++ spec).

Currently, the focus is on just getting the technical underpinnings done.

As for possible APIs, Martin's DConf talk contained some related ideas.

David
September 28, 2013
On Aug 30, 2013 2:45 PM, "Iain Buclaw" <ibuclaw@ubuntu.com> wrote:
>
> Morning all,
>
> It has been about 3 months since the last release of the D front-end
implementation.  Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months.
>
> So I would want to give everyone on the dev team a kick and get the
alpha/beta out the door.
>
> Across D/Druntime/Phobos, there are currently 26 open major bugs since
28/05/2013.
> http://bit.ly/173WrZf
>
> 18 open critical bugs.
> http://bit.ly/16WkhcM
>
> 5 blockers.
> http://bit.ly/18q1pkC
>
> And 14 regressions.
> http://bit.ly/15pLzVb
>

One month gone and 14 of these have now been closed/fixed.  Still seen no signs of moving towards a next release...

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


September 28, 2013
On Saturday, 28 September 2013 at 10:48:49 UTC, Iain Buclaw wrote:
> One month gone and 14 of these have now been closed/fixed.  Still seen no
> signs of moving towards a next release...
>
> Regards

From my point of view two things that are necessary for making this release:

1) working dynamic loading of shared libraries (what is the state of this?)
2) fixing all regression caused by recent symbol emitting changes (at least vibe.d had one on master weak or two ago, did not check it after that)
September 28, 2013
On 2013-09-28 18:48, Dicebot wrote:

>  From my point of view two things that are necessary for making this
> release:
>
> 1) working dynamic loading of shared libraries (what is the state of this?)

I would like to add: only on Linux.

> 2) fixing all regression caused by recent symbol emitting changes (at
> least vibe.d had one on master weak or two ago, did not check it after
> that)


-- 
/Jacob Carlborg