Thanks Jeff What should I see when Yi loads? If my config file is broken, where should I see errors? The debug option didn't produce anything useful. After starting up, the help option does open my config, so I think it is in the right place. This is Windows 7 if that makes any difference. I'm happy to take a look at the source, any suggestions where I should start? Peter On 13 Oct 2010 06:36, "Jeff Wheeler" wrote:

That bug is probably no longer correct. We now use the dyre package for loading the config. Does anybody know if dyre works on Windows in general?

On Tue, Oct 12, 2010 at 5:39 PM, Peter Marks wrote:

...

Does anyone use Yi on Windows? I've managed to get it to build and run, but it doesn't seem to pick up a config file. This seems to be an issue identified over a year ago: http://code.google.com/p/yi-editor/issues/detail?id=269. This would seem to render the editor almost completely useless on Windows. The whole point is to have an editor you can customize in Haskell. Any suggestions appreciated. Thanks

Peter _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- 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

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". 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. 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. 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 7. 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. I'll let you know how I get on. Peter On 13 October 2010 22:31, Jeff Wheeler wrote:

On Wed, Oct 13, 2010 at 2:54 AM, Peter Marks wrote:

...

What should I see when Yi loads? If my config file is broken, where should I see errors? The debug option didn't produce anything useful.

I'd expect it in one of three places:

1. In a buffer inside Yi when it launches using the default config. (I'm guessing this isn't the case for you if you haven't seen the error messages, but it'd be in a buffer called "*errors*" if present. It theoretically should open as the default buffer.)

2. I don't think this should happen, but dyre /may/ make a file yi.errors in ~/.yi/, next to your config file.

3. It might just print it to the console, but that's not happening here, or you would have seen it.

...

After starting up, the help option does open my config, so I think it is in the right place. This is Windows 7 if that makes any difference.

I'm not sure; I've never tried installing much Haskell on my Windows machine, so I haven't tested Yi on it. I think somebody worked on it a while back, but I'm not sure if they succeeded (or if it still theoretically works).

...

I'm happy to take a look at the source, any suggestions where I should start?

Interfacing with the dyre config loader occurs in src/Yi/Boot.hs, but there's also some interesting stuff related to starting up in src/Yi/Main.hs. The dyre package provides the primary entry-point, and calls Yi.Main.main with the relevant config when it's ready to start. Yi.Boot instructs dyre on how to work with configs for yi.

Best of luck, and thanks for playing with Yi!

-Jeff

-- 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

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 wrote:

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

On Thu, Oct 14, 2010 at 1:41 PM, Peter Marks wrote:

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

Oh, indeed. I didn't realize that. The behavior is defined in Yi.Config.Default.nilKeymap and is very stupid about how it calculates the config file location. We should be able to get this path from Dyre instead.

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.

Woah . . .

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.

I think it's only important that they be deleted after a successful compile. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign