I'm surprised no one has mentioned the Visual Studio Shell yet. It's free to use and works great with F#, you can find out more here.

By on 4/30/2009 2:38 PM ()

Microsoft publishes the .NET sdk for free, this and a text editor are all you really need to run F# for free. The text editor is the thing that will make the real difference to you programming experince, at it's heart Visual Studio is really just a text editor that designed for editing programs. Unfortunatly the express editions of visual studio do not support any kind of add on, you can download a time bomed version of visual studio for free that does work with F#.

If you don't fancy using a time limited version of visual studio, then there are lots of other text editors available for download for free, I'm a fan of notepad2, and theres always VIM/emacs etc.

Mono isn't really necessary unless you want to run F# on linux.

Cheers,
Rob

By on 12/10/2006 4:26 AM ()

For what it's worth here are the tools I've been using to develop F# code.

  • Scite for editing (www.scintilla.org/SciTE.html). This editor is designed to feel like MSDev and is very good. One of the few that actually understands Caml. Also supports pretty much every other language I've ever heard of and is very easy to configure. Works on linux too.
  • DbgClr.exe - a very, very good debugger (not that you'll need it much for F#!).
  • ClrProfiler.exe - a pretty good memory profiler
  • nprof.exe - a simple time profiler. Pretty basic, but the only free time profiler I've been able to find. Source code is available too. Seems to work flawlessly with F# from the limited tests I've done.
  • Cygwin for compilation. One point to note is fsi.exe doesn't work very well under cygwin and you're better off using a normal command prompt.

Cheers,

Andy

By on 12/10/2006 9:04 AM ()

Thanks Julien for the xacc link. I'll stay aware of this application :). I tried to configure it for fsharp but it doesn't work...

Thanks Andyman for all those tools. They are very useful !

The important things I try to find is a tool to debug native fsharp code (like in OCaml with the debug mode in the top level of emacs)
Does everybody use the paying Visual Studio tool ?

By on 12/11/2006 9:30 AM ()

Personally I do use the paying version of visual studio, but there is a graphical debugger distributed with the SDK that will give you pretty much the same experince as visual studio distributed with the SDK, which is free. The tool can be found in \SDK\v2.0\GuiDebug, you have to manually attach to the process rather than just being able to press F5. You can also do this with the express versions of visual studio. In both case it doesn't really matter what created the binary the import thing is that the symbol files (.pdb) and source files are in the right place, which is usually just leaving them where you created them.

Cheers,
Rob

By on 12/11/2006 1:13 PM ()

I installed Visual Studio Express C#. Now there is C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0 folder but no GuiDebug folder. There is a bin folder in it but no graphic tool in it. I tried to dowload and install the Visual Studio 2005 SDK but it can but only installed with the paying Visual Studio 2005. Where am I wrong ?

Thanks

By on 12/16/2006 3:19 AM ()

I believe you want the ".NET Framework 2.0 SDK", not the "Visual Studio SDK". The latter is for extending Visual Studio, e.g. with a new language service.

The download for .NET Framework 2.0 SDK is available here: [link:msdn2.microsoft.com]

By on 12/16/2006 5:24 AM ()

Thanks for the reply. I don't want to use FSharp only during 90 days ;)

I already use OCaml on Emacs with tuareg. So I'll probably use Emacs for FSharp.
Here is a post about FSharp & Emacs : [link:cs.hubfs.net]
Don, if you read this, what's new about what you were talking about in this thread ? What should I choose : DeeJay .emacs and tuareg modification or your caml-mode ? What about the James Margetson method ?

By on 12/10/2006 5:05 AM ()

Slightly off topic, but I thought I'd mention that the latest release of F# (1.1.13.8) includes an API to access the implementation of syntax colorization, interactive type checking and some of the intellisense information in a file (not all intellisense information is currently propagated). In principle this should allow a good programmer to embed the F# interactive behaviour into other .NET-implemented editing environments. We've tested this by writing a micro sample using WinForms, but not a complete embedding into another editor.

The API is in FSharp.Compiler.dll, and the most important entry points are shown below.

If anyone starts a community project bsed on this I would strongly encourage you to host the project on CodePlex. Also, while the API below is expected to be largely stable, if you pick up a dependency on the API you should expect the possibility of a small number of changes and extensions to the API in each major revision of F#. Thus you should expect to have to release your project in source code form (to enable others to make changes to keep it in sync), and to aim to keep your code or community project up to date with each major release of F#. Ideally keep in touch with the F# team about the timing of new releases.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 

namespace Microsoft.FSharp.Compiler.SourceCodeServices
type InteractiveColorizer
    with 
        /// Color a line of F# source code, starting with the given lexState.  The lexState should be 0 for
        /// the first line of text. Returns an array of ranges of the text and two enumerations categorizing the
        /// tokens and characters covered by that range, i.e. TokenColorKind and TokenCharKind.  The enumerations
        /// are somewhat adhoc but useful enough to give good colorization options to the user in an IDE.
        ///
        /// A new lexState is also returned.  An IDE-plugin should in general cache the lexState 
        /// values for each line of the edited code.
        static member ColorLine : line:string * LexState -> (LineRange * TokenColorKind * TokenCharKind) array * LexState

        /// Same as ColorLine, but faster since only the resulting lexState is returned. Useful for colorizing
        /// the invisible text leading up to the part of a file that is actually displayed.  
        static member ColorSkipLine : line:string * LexState -> LexState

    end

type InteractiveChecker
    with 
        /// Create an instance of an InteractiveChecker.  Currently resources are not reclaimed.
        static member Create : unit -> InteractiveChecker
        /// Parse and (optionally) typecheck a source code file, returning a handle to the results of the parse including
        /// the reconstructed types in the file
        member ParseSource : source: string * options: ParseOptions -> ParseResults
    end

By on 12/10/2006 5:57 AM ()

Could anyone post updated information about the API in FSharp.Compiler.dll please?
I'm trying to buid a minimal editor in linux using gtk-sharp.
I've just figured out how to colorize code, but i can't succed in making InteractiveChecker work. Sorry about my bad english. Thanks in advance.

Saludos.
Ignacio.

By on 4/24/2009 3:26 PM ()

If anyone starts a community project bsed on this I would strongly encourage you to host the project on CodePlex.

All interesting. I have a toy language in mind that this might work with. Someday-not-so-soon. I have a toolcraft issue with CodePlex (namely the reliance on VSTE), which is a problem for enthusiasts and non-VS/non-Windows platform participants, but I certainly support the principles you state.

By on 12/10/2006 9:23 AM ()

Ok thanks Don but for the moment I haven't the time to develop it ;)

For now, all I want is to be able to edit and compile FSharp code on emacs, with a debug mode like the tuareg top level of ocaml on emacs...

By on 12/10/2006 6:13 AM ()

What do you think if I port the Camelia, a OCaml IDE written in C++ and QT, from OCaml to F#?

Someone knows similar projects more suitable for the purpose?

By on 12/18/2006 3:43 AM ()

Camelia looks like an interesting tezching tool. The implementation certainly would be easier using F# and .NET. The best things would be to combine this with an existing open source editor project such as MonoDevelop etc. so you didn't have to reinvent the wheel and could concentrate on added value related to F# rather than having to do all the editing work.

I'm not sure how much of the implementation would port: the C++/QT will be essentially non-portable. What do you think?

don

By on 12/18/2006 5:08 PM ()

A MonoDevelop Add-in is a good solution... but Monodevelop work on Windows only with Mono (no .NET framework support).

The Camelia IDE is also for Mac and Windows (no source, only binaries), both come bundled with the QT libraries.

IMHO the better choice is to write something from scratch for .NET and Mono...

By on 12/19/2006 2:23 AM ()

[link:blogs.wdevs.com]

I haven't used for a while... but it's free, and supports (or at least "did support") FSharp (I don't know if it takes the most recent syntax changes into account however)

Cheers,

Julien.

By on 12/10/2006 6:52 AM ()

[link:blogs.wdevs.com]

I haven't used for a while... but it's free, ...

Thanks, that's an interesting project. I particularly like the idea of being MSBuild neutral. One more thing for my someday-soon list.

By on 12/10/2006 9:06 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper