ENIGMA Forums

Contributing to ENIGMA => Function Peer Review => Topic started by: TheExDeus on October 31, 2012, 09:18:37 am

Title: working_directory, temp_directory and program_directory
Post by: TheExDeus on October 31, 2012, 09:18:37 am
Hello! Some time ago one good man added working_directory+ to every file io function. This is correct way to do this if working_directory is not the same as the exe directory. This is only true when debugging (which is all we can do in ENIGMA because the lack of the fuc*ing COMPILE BUTTON) as you want the source (gmk, gm6, egm etc.) directory for the program to feel like the exe directory (not the /temp in which it actually is in). The problem is that as the only way to get exe is to copy it out of the temp directory. That means the gmk's position is hard coded in  directory and so breaks the shit out of everything. I tried using parameter_string(0), but that isn't implemented (which it should). Here is a topic showing how it could be done:
http://forums.devshed.com/c-programming-42/winmain-and-argv-argc-474770.html
I wasn't able to do that because I didn't try bothering how to convert unicode string to regular char. Then I noticed  temp_directory and program_directory are not set either. The default behavior for POSIX file functions is to have them relative to the file anyway, so deleting the addition of "working_directory+" returns the correct behavior. So basically what these variables should return:
"Debug or Run"
working_directory = directory of gmk (works correctly now) or exe if launched separately from LGM
program_directory = directory of exe no mater where launched from or in what mode. Should be the same as parameter_string(0)
temp_directory = temporary directory. Should be the same as exe directory.
"Clean build (Compile button)"
working_directory = directory of exe
program_directory = directory of exe no mater where launched from or in what mode. Should be the same as parameter_string(0)
temp_directory = temporary directory

So either FINALLY make the "Compile" button work that automatically sets working_directory to exe directory on runtime. Or make the "Debug" and "Run" buttons pass an argument to the exe which would basically tell the exe that it is run from LGM and then set working_directory to the gmk directory.

Anyone willing to do anything?
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on October 31, 2012, 11:59:09 am
Hi,


What I'm going to do is close my eyes and pretend no one prefixed `get_working_directory()` to the given filename. When I open them, sometime after I graduate, I'm hoping it will be gone.
Title: Re: working_directory, temp_directory and program_directory
Post by: polygone on October 31, 2012, 01:08:26 pm
Why should it not be prepended to filenames? I don't see any downsides.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on October 31, 2012, 02:06:28 pm
If the implementation of get_working_directory is correct, the only thing you are doing is risking formatting problems with the underlying operating system.

So, technically, your solution does nothing. Especially on Linux, where \ is a valid character in filenames. The only thing your "fix" does is waste time. First, time to call the function. Then, time to poll the operating system for the path. Then, time to concatenate strings. Then, time to parse the path that it already had parsed as the working directory.

Your solution also confuses HaRRi, who now apparently misunderstands the concept of a working directory.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on October 31, 2012, 03:07:20 pm
Josh, the reason working_directory HAS to change when launched from LGM is because the working directory should be the one for the source files (just like in GM it has been since the beginning of time). So you don't have to put your .dll files or your .ini files in the temp directory, but they can safely stay with the source. So you must change working_directory via hard coded path and add that to all IO functions when launched from LGM (just like its done now) or change it on runtime with LGM passing the argument. You can't leave the IO functions without the working_directory prefix unless you are changing the working_directory internally for the POSIX functions. Though I think when you launch a program from another programs directory you do change its working directory... now sure why this doesn't work in this case with LGM.

And the "The fucking compile button" shows this: http://pastebin.com/nnaPG6vV

edit: And I do get the concept of working directory, as I showed what all of the three values should be for the two cases.

Another way which seems the best, could be the easiest, and is basically what I mean with "launch a program from another programs directory" is by making LGM do something like this:
"cd c:/source/dir
c:/tmp/compiled_game.tmp"
One of these things is how GM does it.
Title: Re: working_directory, temp_directory and program_directory
Post by: polygone on October 31, 2012, 03:15:58 pm
The implement works fine on Windows, obviously it needs to be catered to other operating systems but whatever that can be sorted but not being on other operating systems I'm not going to be doing that.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on October 31, 2012, 03:23:35 pm
You've missed the point.

Your.
Solution.
Does.
Nothing.
Useful.
Title: Re: working_directory, temp_directory and program_directory
Post by: polygone on October 31, 2012, 08:49:20 pm
It does useful on Windows, just need macro it for other platforms.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on October 31, 2012, 09:24:36 pm
What is it you believe this accomplishes on Windows?


Oh, I see. You people take turns destroying ENIGMA.

The correct implementation of get_working_directory is NOT [snip]{ return working_directory; }[/snip].
The correct implementation of working_directory is [snip]#define working_directory get_working_directory()[/snip] (actually, the correct implementation would move the macro EDL-side, but I digress).
The correct implementation of get_working_directory, on Windows, is as follows:

Code: (CPP) [Select]
string get_working_directory() {
  char wd[MAX_PATH];
  size_t len = GetCurrentDirectory(MAX_PATH, wd);
  return string(wd, len);
}

So, with the proper implementation of that function, and not DatZach's ass-backwards hard-coded path value for the working directory, your code is useless.

In other words, while your code presently holds a function, it is wrong that it should do so.

And now I'm twice as pissed off by this whole scenario.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on November 01, 2012, 05:04:37 am
And how the hell you can say it works fine on Windows when I created a freaking post about it NOT working correctly on Windows or probably anywhere. Poly, working_directory is HARD CODED to the source directory, so when I put the exe somewhere else or actually distribute it then the game will crash for other people, because it won't try writing/reading in the current working_directory but in some random path (e.g. "c:/my_folder_structure/someplace/cool_game/source") and that will cause a crash. I had to change the IO functions back for me being able to send the program to another person.

And Josh, I now agree that working_directory shouldn't be touched, and the path problem should be fixed in LGM's side. LGM should be able to launch the game from the source directory and thus fixing all these problems. So the IO functions should be changed back.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on November 01, 2012, 02:18:59 pm
ENIGMA launches the game. You can change the working directory from which the game is launched by editing the environment ENIGMA creates for it in better_system. You should probably be able to do this without editing better_system.cpp.

I do not recommend defaulting the working directory to the GM6 folder due to the number of novices (and even overconfident experienced users) who end up accidentally scrubbing the contents of the game's working directory while using the file manipulation functions.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on November 01, 2012, 05:08:18 pm
But that is the GM's behavior and for a good reason, mainly, because when you use DLL's or external resources (sprites, sounds etc.) you don't want to put them in temp directory (where they are actually more unsafe) just to be able to run the game from LGM. You want the source file (gmk, gm6, etc.) act like the exe in the file hierarchy. I too had problems that I had to put my FMOD dll inside the temp folder just to launch the game from LGM. In GM I would just put the dll at the same directory as the source.

And if it can be fixed by changing something ENIGMA compiler or LGM then great.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on November 01, 2012, 06:14:25 pm
What I am suggesting is that you talk to Ism about adding a "workbench" setting to LGM. So your folder will be in ~/Games, and your DLLs will be in ~/ENIGMA/Workbench, or just ~/Workbench, or whatever.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on November 02, 2012, 05:54:27 am
Well the more options, the better. Though I personally prefer the GM way of just putting the source directory as the working directory.

And the "Fucking compile button" doesn't work, which you said it did. Maybe Ism can clarify?
Title: Re: working_directory, temp_directory and program_directory
Post by: polygone on November 02, 2012, 10:18:40 am
I personally prefer the GM way of just putting the source directory as the working directory.
This.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on November 02, 2012, 08:10:25 pm
Yeah, and so does everyone else until they toast every file in their directory.
Title: Re: working_directory, temp_directory and program_directory
Post by: polygone on November 02, 2012, 11:09:46 pm
You have to be super stupid to do that. I've never seen a report of anybody doing that in GM and that's a pretty stupid user base.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on November 03, 2012, 05:55:36 am
Exactly, its been like this for years. Anyone can delete their files no matter the working directory anyway. And you can't delete the source file while doing this as its open by LGM at the time. And there is clearly no alternative than your "Workbench" thing which would probably work just the same for people like me, as I would set it to source directory.
Title: Re: working_directory, temp_directory and program_directory
Post by: Josh @ Dreamland on November 03, 2012, 09:22:11 am
DFortun81 did it. He was writing an encryption program that operated recursively. Without knowing it, he ran it on "", which of course was the working directory. All his files became encrypted; problem was, there was no cipher because the encryption algorithm was wrong. Lost everything in that directory that didn't have an EXE to decompile.

LGM shouldn't be keeping a file open for the source until it is ready to write.
Title: Re: working_directory, temp_directory and program_directory
Post by: TheExDeus on November 03, 2012, 10:57:54 am
Well he is special. Nonetheless this needs to happen. Even if I need to enable it somewhere. Or else it makes developing with LGM uselessly harder. Only for some projects of course, but still a hassle. Just like the code window auto-complete box bug is giving useless headaches.