I've sort of got Fsi.exe working as expected on a Mac OS X (Snow Leopard) with Mono. I just noticed a little bit of odd behavior with cut and paste and I was wondering if anyone had seen this.
I've defined the following alias for fsi:
alias fsi='ledit mono ~/FSharp-1.9.7.8_2/bin/fsi.exe --gui-'
ledit is an Ocaml utility that seems to make the keyboard input work correctly--without it, fsi just never seems to read the input. To see what I mean, try Fsi.exe without ledit and enter
let square x = x * x;;
without ledit, it just never seems to parse the input. I mean it never comes back to the ">" prompt after you enter the string. With ledit, the ">" prompt comes back immediately.
Of course the --gui- keeps fsi from displaying all the messages about the lack of System.Drawing etc.
So this all seems to work. The oddity is when I copy and paste code into the FSI, certain characters seem to repeat over and over again. It seems to be conditioned by the size of the buffer I'm pasting in. When I paste small snippets there seems to be no problem. But if I paste in larger chunks, there's this oddity.
If I do the following:
open System.IO;;
then paste this code snippet in FSI:
let buildFileList basepath filespec =
seq {
yield! Directory.GetFiles(basepath, filespec, System.IO.SearchOption.AllDirectories)
}
That works fine. But if I copy and paste in a bigger chunk of code ending with that, it repeats the portion up to the yield! over and over again. It seems to be somehow related to fsi attempting to parse the code as it's being pasted in because the same code pasted in will cause parsing errors (like FS0010) when it's pasted at the end of a long chunk but won't cause an error when it's isolated.
If I #load the entire file, it parses correctly as well so I think my code is ok.
This oddity in copy/paste seems to happen both with and without ledit on the command line. I don't mind researching this issue myself but I'm kind of stumped about where I should proceed with this. I'm copying from GVim if that makes a difference but anyone have any idea where I might proceed in trying to isolate the cause of this odd behavior? I suppose I could take the extra step of copying into TextEdit first and then trying to copy into fsi but any ideas beyond that?
To bottom line this: has anyone else seen this odd behavior? If not, any suggestions about how I might proceed in trying to isolate the cause of this odd behavior?
When I encountered this behavior on my Mac, I went a different route. Instead of using ledit, I employed fsi's --readline option, seen below (where ${FSHARP} is my install path).
mono ${FSHARP}/fsi.exe --readline+ --gui-
You may also want to check your terminal settings. My terminal (for example) is declared as xterm-color, and I have unchecked delete sends CTRL-H. I think those are the only relevant settings, but don't hold me to it.
Related
I am having a problem with text files on my work computer. They are regularly being corrupted and I can't tell if it is an OS problem (Windows 7) or problem with my text editor (Sublime Text 2), or both. Here's what's happening:
I am working on a coding project. I'll write some code, test it out, then save it. It may look something like this (I'm writing in Ruby):
class MyClass
def my_method
end
end
Then later, maybe the same day or the following day, I will attempt to run my code and will get a syntax error or invalid character error or unterminated string error, etc. I trace the error and find that one of my files will look like this:
class MyClass
def my_method
§`½š—ÍÚ
So I'll fix it and close the code blocks, and then run again. Often, I will get a second or third similar error and will have to trace out all of the files where this happens and fix the code.
The 'corruption' always occurs at the end of the file, so usually it is destroying some end statement for a class/module definition, but it also occurs at the end of scripts in the middle of print or puts statements, etc., wreaking a more general brand of havoc. (That is to say, it doesn't seem to only be happening to the keyword end.) The invalid characters that appear are not always the same characters, and so far I have not noticed any repeats. The problem is destroying about 5-10 characters at the end of the file, including new lines (like my example above).
Also, it doesn't seem to be occurring in specific files. But I'm not sure if it is limited to the files in the folder(s) I have open in Sublime text or if it is happening to any files that I open for editing with Sublime text. 99% of the time I'm working in one directory which I have open in Sublime text for my project. I don't know if the problem would occur with another text editor (i.e. Notepad) because I haven't taken significant time to test it out (i.e. coding for a couple of days strictly in Notepad).
The problem occurs in files that are currently (at runtime) open in Sublime Text and have remained open since I last worked on them and saved, and also occurs in files that have been closed since their last use.
This is very frustrating as I feel like I can't trust that my work will be ready to go when I need it, and I have to spend extra time a couple of times a day fixing the files. I have searched for a solution and so far haven't hit on anything that seems to solve or even describe my problem - though I may not be using the best keywords.
Any help is appreciated! Thanks!
I am using Rstudio and not sure how options "run" and "source" are different.
I tried googling these terms but 'source' is a very common word and wasn't able to get good search results :(
Run and source have subtly different meanings. According to the RStudio documentation,
The difference between running lines from a selection and invoking
Source is that when running a selection all lines are inserted
directly into the console whereas for Source the file is saved to a
temporary location and then sourced into the console from there
(thereby creating less clutter in the console).
Something to be aware of, is that sourcing functions in files makes them available for scripts to use. What does this mean? Imagine you are trying to troubleshoot a function that is called from a script. You need to source the file containing the function, to make the changes available in the function be used when that line in the script is then run.
A further aspect of this is that you can source functions from your scripts. I use this code to automatically source all of the functions in a directory, which makes it easy to run a long script with a single run:
# source our functions
code.dir <- "c:\temp"
code.files = dir(code.dir, pattern = "[.r]")
for (file in code.files){
source(file = file.path(code.dir,file))
}
Sometimes, for reasons I don't understand, you will get different behavior depending on whether you select all the lines of code and press the run the button or go to code menu and chose 'source.' For example, in one specific case, writing a gplot to a png file worked when I selected all my lines of code but the write failed to when I went to the code menu and chose 'source.' However, if I choose 'Source with Echo,' I'm able to print to a png file again.
I'm simply reporting a difference here that I've seen between the selecting and running all your lines and code and going to code menu and choosing 'source,' at least in the case when trying to print a gplot to a png file.
An important implication of #AndyClifton's answer is:
Rstudio breakpoints work in source (Ctrl-Shift-S) but not in run (Ctrl-Enter)
Presumably the reason is that with run, the code is getting passed straight into the console with no support for a partial submission.
You can still use browser() though with run though.
print() to console is supported in debugSource (Ctrl-Shift-S) as well as run.
The "run" button simply executes the selected line or lines. The "source" button will execute the entire active document. But why not just try them and see the difference?
I also just discovered that the encoding used to read the function sourced can also be different if you source the file or if you add the function of the source file to your environment with Ctrl+Enter!
In my case there was a regex with a special character (µ) in my function. When I imported the function directly (Ctrl+Enter) everything would work, while I had an error when sourcing the file containing this function.
To solve this issue I specified the encoding of the sourced file in the source function (source("utils.R", encoding = "UTF-8")).
Run will run each line of code, which means that it hits enter at the beginning of each line, which prints the output to the console. Source won't print anything unless you source with echo, which means that ggplot won't print to pngs, as another posted mentioned.
A big practical difference between run and source is that if you get an unaccounted for error in source it'll break you out of the code without finishing, whereas run will just pass the next line to the console and keep going. This has been the main practical difference I've seen working on cleaning up other people's scripts.
When using RSTudio u can press the run button in the script section - it will run the selected line.
Next to it you have the re - run button, to run the line again. and the source button next to it will run entire chuncks of code.
I found a video about this topic:
http://www.youtube.com/watch?v=5YmcEYTSN7k
Source/Source with echo is used to execute the whole file whereas Run as far as my personal experience goes executes the line in which your cursor is present.
Thus, Run helps you to debug your code. Watch out for the environment. It will display what's happening in the stack.
To those saying plots do not show. They won't show in Plots console. But you can definitely save the plot to disc using Source in RStudio. Using this snippet:
png(filename)
print(p)
dev.off()
I can confirm plots are written to disc. Furthermore print statements are also outputted to the console
So I've started to use Anything with Emacs. You can use 'locate' with anything, but you can also use VoidTools' 'Everything' (which is actually the default for 'Windows-NT' systems.
It took a little bit of prodding, but I have command line Everything working on my system. I get results back from it while using anything-locate or anything-for-files.
Everything works fine except I get the dreaded ^M (control-M) at the end of the lines that es returns to me. That means when I use anything to open the file, it doesn't work.
Anyone have any help on how to fix values that es returns, or alternately, strip off the ^M before trying to open the file?
Ah-ha, in the end, it was my fault.
Be careful when messing around with the process-coding-system-alist, and make sure that it's something that really needs to be done. I modified this in the past thus:
(setq process-coding-system-alist (cons '("bash" . (raw-text-unix . raw-text-dos))
process-coding-system-alist))
And I don't need to do that anymore. It meant that the files being passed up from Everything were being interpreted Unix style, and the CR/^M were showing up. By commenting out this line, I solved my own problem.
I love the code completion in Xcode, it saves me a lot of typing work. Also, it confirms my code is probably error-free in real time. However, to me, some code suggestions are disturbing. For example, when I type else after an if-statement, Xcode suggests this:
else {
statement
}
I'd like to change this to just:
else
statement
Because, I quite often just want to use one line of code there, and adding curled brackets goes much faster than removing them. The other annoying thing is the fact that using such a suggestion takes the return key, while a new line does as well. So, if I would want to use my preferred way as shown above, I would first have to press the escape key in order to stop Xcode suggesting it, and then press the return key. Not a real pain, but I think it's unnecessary.
There are some other code suggestions which I would like to change, but I think I have made my point already. Is there a way to change these code suggestions? I know Apple doesn't provide an easy way within Xcode itself, but I'm willing to dive into the finder for the file with suggestions and change it manually. Thanks!
in your example, it would work to add a space after typing else. Doing that removes the brace suggestion and you can just hit enter.
For some reason, I cannot jump forward with <C-I>; gives me the error beep. <C-O> works just fine.
I don't see any remapping going on either. Any ideas what might be the problem?
I'm using vim 7.3 on win7
EDIT: I just found out <C-I> does the same as %! I still can't figure out how to fix it though.
Why does having <TAB> mapped affect <C-I>? The short answer is, "historical reasons", dating from even before the original 'vi'.
The ASCII code for <TAB> is 9, same as <CTRL-I>. Since terminals receive their input encoded in ASCII, they can't tell whether that "TAB" signal came from the actual <TAB> key, or from the user holding CTRL and pressing I. Since Vim was originally written to run on terminals, it can't tell the difference either.
A couple of other pairs of indistinguishable keys are <C-M> with <Return>, and <C-[> with <Esc>.
It's possible there's some arcane way to tell the difference between the two (more likely if you're using GVim), but if there is, I don't know it. As a workaround, you could use nnoremap <SomeOtherKey> <C-I> to give <C-I>'s original function to some other key.
I found a fix for the problem, but I don't know why it works..
I had <TAB> mapped to %. By removing this, <C-I> works as normal.
Any idea why this works...?