The beginning of this past summer, I got a hankering to build an "IDE" for Fan with Fan. I called the project Flux, and it has been the driving force behind the fwt. My basic goal was for Flux to be a simple tool available in Fan distributions as the platform for Fan's graphical developer tools.

Flux is best described as a cross between Finder, Firefox, and TextPad. The browsing model is very similar to a browser, except typically you are "surfing" URIs to the local file system. Like a browser (but unlike a text editor) the default action for opening a file is to replace your current tab. You can open new tabs using Ctrl+T or holding down the Ctrl key when clicking on a resource (Command key on Mac). You'll also get a new tab if your current tab is dirty (has unsaved changes).

The latest Fan build 1.0.32 includes the Flux prototype. This is a very early preview - it is quite rough around the edges. However, it works well enough that Andy and I have already both switched to using Flux as our primary text editor for day to day work!

You can learn more:

• docTools: using flux as a development tool, setting up your options, how to write tool scripts
• docLibs working with the Flux APIs to write your own views, sidebars, and plugins

The entire Flux codebase right now is only around 7000 lines of code (including comments and everything). So it is pretty easy to wrap your head around for hacking.

Here is a screenshot:

Hey Brian,

Can you please provide some help for newbies on how to write simple hello.fan files and compile them using Flux?

Currently, it says it needs a build.fan file, so I added the following:

#! /usr/bin/env fan

using build

**
** Build: hello
**
class Build : BuildPod
{

  override Void setup()
  {
    podName     = "hello"
    version     = globalVersion
    description = "Hello World"
    depends     = ["sys 1.0", "fwt 1.0", "compiler 1.0", "build 1.0"]
    srcDirs     = [`.`]
  }

}

The output says:

\path\tmp\build.fan
compile [hello]
  Compile [hello]
    FindSourceFiles [3 files]
    WritePod [/path/fan/lib/fan/hello.pod]
BUILD SUCCESS [104ms]!

However, that file seems to be a binary file and I have no clue where the output is :)

Regards,

Swaroop

Swaroop - Fan compiles to fcode which is not directly runnable (just like Java does with jar files). To run your code, pass in the podname to the Fan launcher:

http://www.fandev.org/doc/docTools/Fan.html

fan <pod> [args]
fan <pod>::<type> [args]
fan <pod>::<type>.<method> [args]

// so in your case...
fan hello

Andy, does that mean we can only compile using Flux and not run/debug?

Oh yeah, sorry I didn't clarify that. At this point, you only get "build" out of the box. But the Tools menu is actually open ended - so you can hook in your own Tool to do whatever you want. Check out the Flux docs:

http://www.fandev.org/doc/docTools/Flux.html

So you could add a Tool to run your code - though there isn't any debugger support.

First of all, great work! I found Fan just a couple days ago, and fell in love.

When I discovered Java it was at the 1.02 release, like 96 or so, and I had kind of the same reaction to it then as Im getting now: that it's what I'd build for myself if I could. And one of the first things I did then was start work on a side project to build an IDE in the language that had some of the best features of Smalltalk -- full instant access to your codebase, incremental compiling, formatting editor... it got pretty far; I had all those things working, and class decompiling, dependency analysis... but there were no widgets. Every thing I needed (trees, tips, toolbars, buttons...) had to be built from scratch. So the project ended up kind of dying due to I needed to eat.

And here's Flux and Fan, looking like an exact framework for doing what I was trying to do then. So the first thing I want to do is add a sidebar tool that uses reflection (and maybe the TypeDatabase? but the docs aren't saying much about its api, or actually I haven't got to the right docs yet) to discover all pods/types/slots in the system, and displays them in tree form. Like the Object Inspector doohickey in VisStudio.

And the second thing I want to do is update the editor with hover help, using tooltips to present all available info about types/parameters/etc as needed. It's unbelievable how big a help that is when learning new libraries.

Third is code folding in the editor; or actually what I'd like is better. I've been thinking, with reflective knowlege of the class you're editing, why not just present the class in summary form:

ClassX *first few words of its doccomment*
  Method1 
  Method2
  Field1

etc., and you'd doubleclick a method to open it for editing, or rightclick/ New Method to get a blank template to add one, like, and you enter some code and hit Accept and get it instantly compiled into your class. All Smalltalky-like. :-)

Fourth is ...well, anyway I'm going to be busy. (Fan's on High :-) But I'm looking at getting hard into this for at least the next couple weeks, so I guess what I want to know is, is somebody already working on Flux currently? I see the last date here is Sept'08, and that's the last date I find on the code in the distro. So are you guys all busy with other stuff, or is there something that just hasn't been dropped in yet?

Anyway, thanks for making this thing. You've given me back hope :-)

Kevin

"add a sidebar ... to discover all pods/types/slots in the system, and displays them in tree form" we already implemented this in the IntelliJ plugin if you are interested.

For info the version 0.0.2 of the plugin has (from mercurial repo http://hg.jfrog.org/hg/fan4idea/ ) already the following features:

• Syntax highlighting
• Building a Pod and Java stubs
• Running a Fan script
• Fan module support
• Auto generation of Pod build script
• Synchronization between Fan module and Pod build script (currently one way synchronization)
• Pods can be added as module libraries.
• Contained classes are indexed
• Sources are also indexed if available
• Fan SDK support
• Structure view
• Go to class (ctrl + N) including non project classes
• Go to symbol
• Go to decleration (ctrl + B)
• Brace matching and highlighting
• Auto closing open quotes
• Comment/uncomment with line/block comment
• Support Ctrl+H hierarchical view

Everyone that wants to help on the plugin is welcome. There is already a branch for Expression parsing (quite hard, but almost there http://hg.jfrog.org/hg/fanp14/ :), so we'll be happy to have anyone supporting us in our efforts.

Fred.

Kevin,

Thanks for the positive feedback!

and maybe the TypeDatabase? but the docs aren't saying much about its api

You probably don't need the type database - you typically use that for late binding of types keyed by facets. For example if you want to register a view in flux for a specific file extension. Take a look at Pod.list, Pod.types, and Type.slots.

guess what I want to know is, is somebody already working on Flux currently

Andy and I built Flux last summer for a couple reasons:

• as a use case for the FWT APIs to really apply them to a real application
• as an editor for ourselves (we both use Flux exclusively for all our development now)
• as a pluggable UI framework for future Fan tooling

Currently we are splitting our time between our new startup SkyFoundry and getting Fan into shape for a 1.0 release. So I'd say right now getting the language and core APIs wrapped up is top priority (versus enhancing Flux). But we are definitely going to get back to Flux and keep enhancing it.

I do believe IDE support in general is critical for Fan's success. We've built Flux as something 100% in Fan, but I don't want to exclude Una, NetBeans, Eclipse, IntelliJ, etc. One of the key sub-systems which all IDEs require is a background incremental parser which can be used by the IDEs for modeling the AST in its current state. This model can then be used for type/slot navigation, auto-completion, and instantaneous error highlighting. See previous discussion.

I would really like to rally the community around a shared incremental compiler for IDEs. But I don't know everybody's requirements. My personal, basic requirements for Flux:

1. it must be written in Fan
2. it must use Fan's actor model for concurrency

BTW - Andy and Fred, if you guys meet up again in Vegas today maybe you can talk this issue out a bit

Fred-

I took a quick look, very nice! I'm more wanting to use/write Fan right now, but hopefully there'll be some feed-across going on.

Brian, those reflection APIs look like exactly what's needed, thanks.

I agree strongly with "Flux ... must be written in Fan"; I've been the last few months using Smalltalk and it's reminded me how strongly I believe in that "turtles all the way down" idea, a language written in itself, able to modify itself (even on the fly) all the way through the compiler and down into the virtual machine if possible. There's an incredible benefit when all the code to all the tools you're using, and whatever else you've written, is available at your fingertips for extension and adaptation.

That point ties in with your mention of the AST, by the way. In course of tinkering around inside Squeak Smalltalk I ran across its use of the AST generated by the Refactory (another thing for the wish list, btw: support for Refactoring Browser functionality) to make a nice simple and clean implementation of syntax highlighting. Smalltalk syntax is a whole lot easier to do that with of course, but once you've got the AST it's useful in all kinds of ways.

I'm at this point very new to Fan, but very excited about it, and pretty sure I can make use of it and in process maybe help make it better. As a means of getting up to speed with the syntax, features, semantics, libraries, all that, I'm really liking the idea of working for a while on adding to Flux. There's the added benefit of gaining a tool that works more as I want it to.

So far I've been systematically going through the Doc Home pages, and have pretty well mostly more or less assimilated that :-), down to the level of only skimming the specific class api docs, at least.

I do believe IDE support in general is critical for Fan's success.

100% agreed. I would recommend it as the #1 Fan priority after finalizing Fan 1.0 itself. Nothing will compete with Java head on without killer IDE support. And it's something that nothing other than Java has (that I've seen), in an open source fashion. At least, I haven't seen anything open source even close to as good as Java IDEs.

After stabilizing Fan itself and then IDE support (and I do like the idea of Flux in addition to support for other IDEs, which can be done 3rd-party), I personally think the next most important thing is deployment (into pods and out to various platforms). But I'm getting way off topic here, and I'm not much of a helper these days. But maybe again some day.