
Are you sure that Yi ever writes a default config file?
If dyre defaults to using a directory that doesn't exist on 7, I'd say
If you start Yi with no config file, press any key, press "h", choose a key
binding, then save the file, you get a file c:\Users\peter\.yi\yi.hs
that's a bug in dyre. We should probably tell Will Donnelly (the
maintainer) if that's correct.
Hmm, although what I said is correct, it is not causing this problem.
Windows 7 does use a different directory for local user data, but it
implements some magic to make references to the old location access the new
location. If you do a dir of "C:\Users\peter", "Local Settings" doesn't
exist, but if you dir "C:\Users\peter\Local Settings\Cache\yi", you actually
get the contents of "C:\Users\peter\AppData\Local\Cache\yi", which does
contain the file "errors.txt"! It is a sort of invisible simlink.
The actual problem I am having is that dyre tries to delete "errors.txt"
straight after reading it with readFile. As readFile is lazy, the runtime is
keeping the file open so, on Windows at least, it can't be deleted. I'm not
really sure why it wants to delete the file though. I guess it is so that
any warning messages are only shown the first time you launch after a
compile, then deleted. I don't see why the errors file can't just be left so
that you see errors whenever you launch. I'll try changing this later this
evening (UK) and let you know if it works. The alternative would be to force
the file to be read strictly then closed.
Peter
On 14 October 2010 00:53, Jeff Wheeler
On Wed, Oct 13, 2010 at 6:14 PM, Peter Marks
wrote: The problem is down to getAppUserDataDirectory called in Yi.Boot. This function behaves differently on Windows to Linux... and more so on Windows 7. The first issue is that on Windows it doesn't prepend the "." to the directory name, so it is looking in "yi", not ".yi". On Windows 7, it looks for this directory in a completely different location: "C:\Users\peter\AppData\Roaming" rather than just "C:\Users\peter".
This sounds right.
Obviously other parts of the program are using a different call to locate the config file as, letting the editor create the default file, it places it in "C:\Users\peter\.yi\yi.hs"! I can't find the code that does this at the moment - any pointers appreciated.
Are you sure that Yi ever writes a default config file? As far as I know, when dyre provides no config from reading a file (or resuming a saved state), Yi will boot with Yi.Config.Default.defaultConfig (that's the one that lets you enter vim or emacs keybindings with 'v' and 'e' respectively), but I don't think it ever writes this to a file. (Note that src/Main.hs calls this; it might make sense to remove that file and move this to Yi.Main or Yi.Boot.)
My current feeling is that getAppUserDataDirectory is the correct call to use and the docs should be changed to tell users to put their file where this call points. Further, it would be nice if the editor told you where it was looking if it doesn't find a config file... well actually, when it does find a file too, so you know which one it loaded.
I'm in favor of printing it when an error occurs (should no config be an error? not sure, but I'd be inclined to say no). When Yi boots correctly, I'd prefer to not print anything.
Or, better yet, just always include it in --debug.
This is now "AppData\Local" I think. Setting the cacheDir field of the dyre Params should fix this, but I don't have time to try it right now.
Now I'm on to the next problem, it tries to write its error file in a location that doesn't exist: "C:\Users\peter\Local Settings\Cache\yi\errors.log". "Local Settings" doesn't exist on Windows
If dyre defaults to using a directory that doesn't exist on 7, I'd say that's a bug in dyre. We should probably tell Will Donnelly (the maintainer) if that's correct.
Again, thanks so much for looking at this.
-- Jeff Wheeler
Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe