Mudlet dev file location debug controls

[SlySven]

This extends (and replaces) #31 so that Developers and others can force the use of Mudlet lua files in a sub-directory of the src one (specifically ./../src/mudlet-lua/lua ) where . is the build directory from which we are (temporarily ?) running the Mudlet executable. Note that the '..' in the path is to force a change UP to the parent directory before descending to the src one to accommodate what Qt calls shadow builds and coders (and the alternative CMake build system) would call out-of-source builds - though this will only work if the build directory has the same parent as the src one! In-Source builds won't be affected by such path name twiddling as ./../src/ would then be a no-op.

Bottom line is that there is a check-box on the last tab of the profile preferences dialogue with an area reserved for developer run-time tweaking controls and there will be a check-box to force the use of source directory lua files ignoring an installed set where-ever else they might be. The replaced pull request, like this one, causes Mudlet to check for and moan to the user if the main Mudlet & geyser lua file loader luaGlobal.lua cannot be found before inviting the user to go on a hunt for this specific file. The code is OS-agnostic and once the file IS found it is stored for future reference and the location is used until the file cannot be found at the given location at which point Mudlet will bring this fact to the user's attention again. At this point there is no code in place for user intervention to change the location - deliberately - though it can be forced by deleting the relevant line from the Mudlet configuration file.

The OS specific part is the default place where Mudlet first tries to find the needed loader, the qmake project file src.pro creates a preprocessor defines LUA_DEFAULT_PATH which is hard coded in and the OS specific stuff is creating the value for that define. Other build systems maintainers (I'm looking at the gentleman working on the CMake system) will need to ensure that they find a way that (for instance on a GNU/Linux system using gcc) will cause something like -DLUA_DEFAULT_PATH=\"/usr/local/share/mudlet/lua\" to be used when compiling the project...

[vadi2]

There's an issue with this, could you have a look?

Host.cpp:168: error: undefined reference to 'vtable for Host'
Host.cpp:334: error: undefined reference to 'vtable for Host'
Host.cpp:385: error: undefined reference to 'vtable for Host'

[SlySven]

The Host class gains the QOBJECT macro which means the Qt MOC will have to consider it now (for SIGNAL/SLOT stuff at least). I think it is possible that you need to do a "make clean" on the source ("Clean project 'src'" on the QtCreator build menu) - or at least zap all the moc* and ui_* tempory files and running qmake on the project.

It's a pain, and for me means at least a 30 minutes recompile but those of you with massively overprocessored systems probably won't notice the delay... 8-P

Try that and see, and I'll also take look another look at it...

... 40 minutes later:

Humm, no problems rebuilding it. I think that must be it, a dirty source tree.

S

On 19/04/14 05:42, Vadim Peretokin wrote:

There's an issue with this, could you have a look?

Host.cpp:334: error: undefined reference to 'vtable for Host' Host.cpp:385: error: undefined reference to 'vtable for Host' |

— Reply to this email directly or view it on GitHub https://github.com/Chris7/Mudlet2/pull/34#issuecomment-40860656.

[vadi2]

I cleaned it several times, nothing bulged, used clang instead of gcc and it worked. Oh well!

I'm still having the issue, when launching from Qt Creator, it is saying it failed to locate the Lua files - yet it should find the mudlet-lua/ that is adjacent to the binary and use it. That is the logic that we've had before; it should still support this scenario. Could you take a look?

[SlySven]

But I'm not seeing any sign of moc_Host.* files which is what I'd expect if QtCreator had taken note that the Host class NOW has the "Q_OBJECT" macro inside it. Running "qmake" should cause the IDE to notice the change... but sometimes this doesn't seem to happen auto-magically.

Are you getting a polite dialog moaning about not finding "essential Lua files" and asking you to go and find LuaGlobal.lua with a native file open type dialog - which you use to find the offending file - but upon finding it and using the "open" or "OK" on that native file dialog it reports a bit later - on the profile's screen (using the mechanism I've been bugfixing that reports Lua startup / connection to MUD server messages in the last day) - that it failed to find the Mudlet & Geyser API files?

Using a debugger what is the value returned by mudlet::self()->getSystemLuaPath() which is called several times in TLuaInterpreter::loadGlobal()?

That value is added to the list of places the the Lua interpreter looks to find files ( package.path ) and also, using the lue file system module, it is made the "current directory" before the tweaked LuaGlobal.lua in the commit is read in and executed (which now does NOT look outside of its current directory to load the other core Mudlet lua files and a "geyser" direct subdirectory to load the geyser files), after doing so the current directory is changed to the directory in which the mudlet executable is running. Both the add to path+change directory before LuaGlobal.lua is executed and the change to mudlet executable directory after are reported on screen using the, now "ex-" gSysMessage system so I'd be curious to see what is being shown if you can take a snapshot.

On 20/04/14 21:32, Vadim Peretokin wrote:

I cleaned it several times, nothing bulged, used clang instead of gcc and it worked. Oh well!

I'm still having the issue, when launching from Qt Creator, it is saying it failed to locate the Lua files - yet it should find the mudlet-lua/ that is adjacent to the binary and use it. That is the logic that we've had before; it should still support this scenario. Could you take a look?

— Reply to this email directly or view it on GitHub https://github.com/Chris7/Mudlet2/pull/34#issuecomment-40904128.

[Chris7]

Is it possible to recreate this pull request starting from the current branch (so there aren't any more merge conflicts) and without the development specific things?

[SlySven]

If you mean, without the translucent 2D room hack - yes I think so - I'll pull my mudletDev tracking branch to match yours now.

[Chris7]

Thanks. On Jun 3, 2014 11:03 AM, "Stephen Lyons" notifications@github.com wrote:

If you mean, without the translucent 2D room hack - yes I think so - I'll pull my mudletDev tracking branch to match yours now.

— Reply to this email directly or view it on GitHub https://github.com/Chris7/Mudlet2/pull/34#issuecomment-44976185.

[SlySven]

I have modified both mudletDev and this branch and then performed the required merge of this into my mudletDev branch - so I guess if you can pull from my mudletDev branch back into yours that would do what needs to be done - alternatively I can send you a set of notes to manually resolve the merge conflicts if you really want to do it yourself...!