Phonebook example regression

[GreatEmerald]

The phonebook example no longer works when compiling with RDMD on 64-bit Linux, it returns these errors:

LuaD/luad/conversions/structs.d(51): Error: no property '__fieldDtor' for type 'Contact'
LuaD/luad/conversions/structs.d(51): Error: (Contact).__fieldDtor cannot be resolved
LuaD/luad/conversions/structs.d(54): Error: no property '__fieldDtor' for type 'Contact'
LuaD/luad/conversions/structs.d(54): Error: no property '__fieldDtor' for type 'Contact'

Additionally, it still wouldn't work correctly since contacts.lua has been moved, yet line 31of phonebook.d was not changed to reflect the change.

[JakobOvrum]

Strange as it would be, this could be a 64-bit specific bug. The phonebook example works fine on this 32-bit machine. Which version of DMD are you using?

The phonebook example is meant to run in the (new) example/bin directory, and I didn't want to duplicate contacts.lua. I originally had a post-build step set up in the VisualD project file to copy the script to the output directory on build and delete it again on clean, but it caused Visual Studio to crash on another machine. Running the examples with rdmd is definitively worth supporting though, for the sake of simplicity I think it's best to keep both copies in the repository. I don't expect contacts.lua to change any time soon, anyway.

[JakobOvrum]

( see 3c276ad12c2732aff716 )

[GreatEmerald]

DMD v2.054. I did some further testing, and it works - somewhat. That is, it does compile, but it still crashes once the execution of it stops. It compiles both when and when not using openLibs(). So the issue I had here originally is something else entirely, because I tested this on a somewhat modified phonebook example. I'll see if I can trial and error that issue out.

As for the directories, doesn't Git support symlinks? I know the symlink files can be added to projects themselves, but of course they won't work on Windows. There should be a way to tell Git to make a symlink internally, however, so that on pull it would automatically duplicate the file on the local machine...

[GreatEmerald]

Aha, I found what's breaking my version. In Contacts, I also had a LuaFunction. Apparently, getting LuaFunctions is now broken. Here's what I have in my phonebook.d:

LuaFunction f; // Inside struct Contact
//<...>
writefln("%s, %s - %s (%s). Function returns %s", contact.surname, contact.forename, contact.number, contact.email, contact.f.call!int()); // Inside main()

And in contacts.lua, inside Contact{}:

f = function () 
    return 1 
end;

[JakobOvrum]

I did some further testing, and it works - somewhat. That is, it does compile, but it still crashes once the execution of it stops. It compiles both when and when not using openLibs(). So the issue I had here originally is something else entirely, because I tested this on a somewhat modified phonebook example. I'll see if I can trial and error that issue out.

It now works with or without calling openLibs, as doString|File now don't use debug.traceback unless explicitly asked for. It's not a design I particularly like, so I'll get back to it later (also, LuaFunction definitively needs a pcall method which would alleviate this a little).

The struct reading code is a little sloppy at the moment. It doesn't do a very good job at ignoring various special members or static members.

As of one of the latest commits I seem to be getting an OutOfMemoryError as the phonebook program shuts down, followed by a crash. I'll have to look into it (probably has something to do with destructors).

As for the directories, doesn't Git support symlinks? I know the symlink files can be added to projects themselves, but of course they won't work on Windows. There should be a way to tell Git to make a symlink internally, however, so that on pull it would automatically duplicate the file on the local machine...

Multiple hard links to the same file does work on Windows from Vista and up.

But sadly, a symlink won't really work here. If you make a link, add it to the repository, then change to a different branch and back again, you'll end up with two copies. Of course, the same happens when you push and pull.

Aha, I found what's breaking my version. In Contacts, I also had a LuaFunction. Apparently, getting LuaFunctions is now broken. Here's what I have in my phonebook.d:

Thanks, I'll have a look.

[JakobOvrum]

The previous commit actually fixes the issue, but also causes DMD to fail with Internal error: ..\ztc\cgcs.c 363. The ICE only happens because of the tweaked unittest; the old unittest without composing LuaObject works fine with the same changes to fillStruct, so I don't think it's something I can easily work around :S

Anyway, the fix is on the struct-ice branch, if you want to try it.

[JakobOvrum]

By the way, as a temporary workaround, you could try changing the f field to int delegate() f;.

[JakobOvrum]

I decided to merge the struct-ice commit into master, but with an additional commit commenting out the part of the unittest causing it to fail. Perhaps it will work on Linux, and besides, the struct unittests aren't very thorough.

[GreatEmerald]

But I can't call the function, then:

LuaTest.d(37): Error: no property 'call' for type 'int delegate()'
LuaTest.d(37): Error: no property 'call' for type 'int delegate()'

[JakobOvrum]

delegate is one of D's function pointer types. You call it like any other function, contact.f().

[GreatEmerald]

Oh, I see. As for the internal error, I get it on Linux as well with the latest commit.

[JakobOvrum]

But only when composing LuaFunction (or any type with LuaObject) in the Contact struct, right?

[GreatEmerald]

Yes.

[JakobOvrum]

I'll make a reduced test case and report it on the DMD bug tracker later.

[JakobOvrum]

Fixed the ICE, was caused by pushStruct trying to push the opAssign method which gets automatically generated when structs have non-trivial struct members.

9e3baa6f790a10f94791