On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:
> I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was disappointed to learn that the only way to call D functions from Lua is for the lua code to be 'inside' a D module. (string l = "lua goes here"; or similar)

I don't understand "inside a D module"

void someFun(string content) { ... }

lua["someFun"] = &someFun;

lua.doFile("SomeFileName.lua");

On Thursday, 21 February 2013 at 17:02:06 UTC, Dmitry Olshansky wrote:
> 21-Feb-2013 12:48, Rikki Cattermole пишет:
>> On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh wrote:
>>> On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
>>>> On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
>>>> [...]
>>>> >>
>>>> >>Yes. Shared Libraries Please.
>>>> >>
>>>> >>Thank you.
>>>> >
>>>> >+1
>>>> >
>>>> >It's the most important issue for me. Particular feature bugs >can
>>>> >be worked around, lack of shared library support is
>>>> >>insurmountable
>>>> >for many applications.
>>>>
>>>> Yes, it's a major barrier towards adoption in a production
>>>> environment. Walter said it's now a priority, so I cross the fingers
>>>> and hope.
>>> [...]
>>>
>>> Better yet, maybe more of us should start delving into DMD's code...
>>> Currently only a small number of people really understand the compiler,
>>> which has a rather low bus factor. We need to increase that (not only to
>>> improve the bus factor, but also so that more people are aware of
>>> compiler issues and hopefully how to fix them).
>>>
>>>
>>> T
>> I just want to say, as I have only worked in D for ~6 months the usage
>> of Optilink is a real pain.
>
> Checkout this alternative linker:
> ftp://ftp.styx.cabel.net/pub/UniLink/
>
> The only issue is that it converts debug info to some other format compatible with Borland's tools (TDS?).
>
>> Couple of days ago I took a strong look at removing 64bit only code from
>> Coff support and allowing it to compile 32bit.
>> I failed yes.
>> But I definitely will take another look into this.
>> Hopefully learn wayy more of how it works!

Been there tried that. Wasn't terribly happy with it.
The removal of 64bit code generation in coff format isn't a killer for me.
But it does make it harder. I can make do without it as I really only want my apps to be running on newer i5+ gear.
Its more of something to learn the compiler and help the community out a bit. Since I know that there will be others that would think this is a killer for not using D.

On 02/21/2013 11:13 AM, Jesse Phillips wrote:
> On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:
>> I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was
>> disappointed to learn that the only way to call D functions from Lua
>> is for the lua code to be 'inside' a D module. (string l = "lua goes
>> here"; or similar)
>
> I don't understand "inside a D module"
>
> void someFun(string content) { ... }
>
> lua["someFun"] = &someFun;
>
> lua.doFile("SomeFileName.lua");


D starts lua, and lua finishes before D.
That fits my definition of 'inside a D file' but I admit I should have chosen my phrasing better.

Try lua starts D, and D finishes before lua.

Those are two different approaches:

> D starts lua, and lua finishes before D.

It's _embedding_ LUA in D. Can be easily done now.

> Try lua starts D, and D finishes before lua.

It's _extending_ LUA with D. Requires good D shared library support. :(

On Wednesday, 20 February 2013 at 21:05:42 UTC, bearophile wrote:
> I am not intelligent (and experienced) enough to design the currently missing/broken parts of D. Is someone able to?

If one writes a short description of problems, then it will be easier to find people and ideas. For example, I have no clue what's wrong with `shared`.

On 02/22/2013 04:51 AM, FG wrote:
> Those are two different approaches:
>
>> D starts lua, and lua finishes before D.
>
> It's _embedding_ LUA in D. Can be easily done now.
>
>> Try lua starts D, and D finishes before lua.
>
> It's _extending_ LUA with D. Requires good D shared library support. :(


Thanks for setting me straight.

On Thursday, 21 February 2013 at 08:07:34 UTC, Brad Roberts wrote:
> On 2/20/2013 4:55 PM, Rob T wrote:
>> Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the
>> fingers and hope.
>> 
>> --rt
>
> It's _a_ barrier for adoption in _some_ production environments.  So are many other features for many other
> environments.  It's really easy to over color the priorities based on your own use case.  The community is large with
> lots of needs.  Juggling priorities is a very grey process.

I think there's a lot more to it than that. For example, if D supported shared libs that can be integrated with C/C++ code then adoption in a production environment becomes much less risky and much more practical. For example, instead of recoding an entire C++ app in D, one could instead include a shared lib that adds on functionality. Shared libs provide a means to migrate into D without the all or nothing approach, and that what is currently one of the major barriers towards adoption.

> Hope is about the least likely to produce results (other than maybe disappointment).  I highly encourage those with
> needs to actively help address them.  It doesn't take a lot of people to add a lot of value.
>
> My 2 cents,
> Brad

I agree, and I have tried to help in small ways. I'll try and do more when I can and as I learn more.

--rt