Page 2 of 3

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 3:08 am
by coffeecat
ffi.C does not contain symbols from love.dll on Windows, see LuaJIT documentation (http://luajit.org/ext_ffi_api.html):
ffi.C
This is the default C library namespace — note the uppercase 'C'. It binds to the default set of symbols or libraries on the target system. These are more or less the same as a C compiler would offer by default, without specifying extra link libraries.
On POSIX systems, this binds to symbols in the default or global namespace. This includes all exported symbols from the executable and any libraries loaded into the global namespace. This includes at least libc, libm, libdl (on Linux), libgcc (if compiled with GCC), as well as any exported symbols from the Lua/C API provided by LuaJIT itself.
On Windows systems, this binds to symbols exported from the *.exe, the lua51.dll (i.e. the Lua/C API provided by LuaJIT itself), the C runtime library LuaJIT was linked with (msvcrt*.dll), kernel32.dll, user32.dll and gdi32.dll.
This semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 3:11 am
by zorg
modiX wrote: Thu Feb 15, 2018 7:56 pm
EDIT: So here is my working function. I could not use isDirectory, because it was always returning false. I think this is an issue with PhysFS. I solved it by calling recursion in any case and trying to get directory items of files, too.
isDirectory may also be coded in such a way to insta-return false if the directory isn't one of the "sanctioned" ones, but i haven't checked the source, just guessing.
modiX wrote: Thu Feb 15, 2018 7:56 pmDisclaimer: I know it can be improved, but this won't be used in a game anyways.
Leave that to me :p

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 10:25 am
by pgimeno
coffeecat wrote: Fri Feb 16, 2018 3:08 amI think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
Does not work for me in Linux.

Code: Select all

$ love .
Error: main.lua:8: liblove.so: cannot open shared object file: No such file or directory
The best thing would be that Löve can mount any directory without limitation.

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 11:47 am
by coffeecat
Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path to liblove.so in LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.
The best thing would be that Löve can mount any directory without limitation.
Why do you need this feature? I am genuinely asking.

I can see that a set of mount points statically specified in love.conf() for development purposes may be helpful. These mount points should be writeable via love.filesystem for soundness of LOVE API design, and the current semantics needs to be revised somehow (otherwise all writes goes to the save directory).

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 11:57 am
by grump
coffeecat wrote: Fri Feb 16, 2018 11:47 am Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path of liblove.so to LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.
I would need to ffi.load('liblove.so.0'). There is no liblove.so.
The best thing would be that Löve can mount any directory without limitation.
Why do you need this feature? I am genuinely asking.
People are not only making games, they're making tools for their games too. Every toolset needs a way to import data, and drag & drop is not a viable substitute for a file selection dialog. I also want to save stuff anywhere on occasion, when I don't wanna make my users go find the magic hidden location where the data was saved on their system.

The current state of things requires a bunch of work to get a very basic thing working. It's a major pain in the ass for no good reason at all.

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 12:04 pm
by coffeecat
I would need to ffi.load('liblove.so.0'). There is no liblove.so.
Just for your information, I have a liblove.so on my system. This is probably Linux distribution-dependent.

Thanks for the explanation.

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 12:05 pm
by zorg
pgimeno wrote: Fri Feb 16, 2018 10:25 am
coffeecat wrote: Fri Feb 16, 2018 3:08 amI think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
Does not work for me in Linux.

Code: Select all

$ love .
Error: main.lua:8: liblove.so: cannot open shared object file: No such file or directory
The best thing would be that Löve can mount any directory without limitation.
If this only happens because you tried to do ffi.load("love") then you missed the fact that on linux, you don't do that.
Look here:

Code: Select all

local l = ffi.os == 'Windows' and ffi.load('love') or ffi.C

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 12:07 pm
by grump
coffeecat wrote: Fri Feb 16, 2018 12:04 pm Just for your information, I have a liblove.so on my system. This is probably Linux distribution-dependent.
It probably is. Is there a liblove.so.0 on your system?

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 12:08 pm
by coffeecat
It probably is. Is there a liblove.so.0 on your system?
Yes. There's also a "liblove.so.0.0.0". I am using NixOS.

Re: Enumerate files outside of root / save directory, recursively

Posted: Fri Feb 16, 2018 3:18 pm
by pgimeno
zorg wrote: Fri Feb 16, 2018 12:05 pmIf this only happens because you tried to do ffi.load("love") then you missed the fact that on linux, you don't do that.
I was just objecting to coffeecat's proposal to always load love:
coffeecat wrote: Fri Feb 16, 2018 3:08 amThis semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

My Löve binaries are statically linked anyway (because I compiled them that way), therefore there's no liblove.so to load.

The best thing to do may be to pcall ffi.C.PHYSFS_mount and try to load love only if that fails.