Random brain dump on various aspects of the Fan runtime and development environments...
Env Variables Need a unified mechanism to deal with environment variables, global settings:
Should fan.exe use JVM or CLR by default (needed by C launcher code)
Global version so that we can roll build number without touching a bunch of files
System.properties kind of variables
My current thinking is that anything that resembles a string name/value pair will be handled via "system properties". Properties will be persisted using a file format like Java properties files - the defaults will be stored in something like "/lib/sys.props". All shell variables, platform properties (Java's System.getProperties), and "sys.props" will be merged into a single global hashmap accessible via Sys.env().
Launcher
I want to replace the launcher scripts with something more robust - a suite of native executables that parse sys.props then launch the JVM or CLR based on current settings. I'll probably write this code in C.
Runtime Dir Tree
An "installed fan image" will look something like this:
The big change we need to make when we switch to the Fan compiler is that the compiler needs to be run from a stable build separate from the development code. Then we need a clean way to perform a full build, run thru the test suite, then verify the new build can build itself so that we can bootstrap to start using the new build as the stable build. While we're at it we might as well figure out what the dev tree looks like to maintain multiple branches. I haven't given this a lot of thought yet, but I suspect something like this:
The Ruby scripts and batch files we are using now to manage the build environment are one of the things that I'm thinking need to be replaced sooner rather than later. We know we want something like Ruby Rake which uses Fan scripts to manage builds:
pod manifest meta-data such as name, version, dependencies, etc
build info like source files, resource files, natives
meta-date like props file, localization, documentation, etc
open ended scripting using Fan for special cases and "top level" build scripts
I'm thinking there is a new "fake" pod that defines a fake::Build class and maybe some specialized subclasses like BuildPod, and then you would create a "fake.fan" script in the top level of each of your modules. Need to do a lot more brainstorming on this one.
brianSat 28 Oct 2006
I added the following methods to support the Fan props format:
InStream.readProps
OutStream.writeProps()
File.readProps
File.writeProps(Str:Str)
Map.get(K key, V def) // support default parameter
Props are just a Str:Str map. This format will be used to handle environment variables, and also localization. The prop format is based on Java properties files, but uses UTF-8 and Fan style comments:
Input must be UTF-8 encoded (current charset is ignored)
Name/value pairs formatted as logical line: <name>"="<value>
Any Unicode character allowed in name or value
Leading and trailing whitespace trimmed from both name and value
Duplicate name keys within one file is an error condition
Comment to end of line is //
Block comment is /* */ (may be nested)
Use trailing \ to continue logical line to another actual line, any leading whitespace (space or tab char) is trimmed from beginning of continued line
Fan Str literal escape sequences supported: \n \r \t or \uxxxx
The $ character is treated as a normal character and should not be escaped, but convention is to indicate a variable in a format string
Convention is that name is lower camel case with dot separators
brian Wed 25 Oct 2006
Random brain dump on various aspects of the Fan runtime and development environments...
Env Variables Need a unified mechanism to deal with environment variables, global settings:
My current thinking is that anything that resembles a string name/value pair will be handled via "system properties". Properties will be persisted using a file format like Java properties files - the defaults will be stored in something like "/lib/sys.props". All shell variables, platform properties (Java's System.getProperties), and "sys.props" will be merged into a single global hashmap accessible via Sys.env().
Launcher
I want to replace the launcher scripts with something more robust - a suite of native executables that parse sys.props then launch the JVM or CLR based on current settings. I'll probably write this code in C.
Runtime Dir Tree
An "installed fan image" will look something like this:
fan-1.0.42/ bin/ fan.exe fant.exe fake.exe lib/ sys.props fan/ java/ net/Pretty much exactly like we are using now.
Developer Dir Tree
The big change we need to make when we switch to the Fan compiler is that the compiler needs to be run from a stable build separate from the development code. Then we need a clean way to perform a full build, run thru the test suite, then verify the new build can build itself so that we can bootstrap to start using the new build as the stable build. While we're at it we might as well figure out what the dev tree looks like to maintain multiple branches. I haven't given this a lot of thought yet, but I suspect something like this:
dev/ builds/ fan-1.0.1/ fan-1.0.2/ dev-1.0/ dev-1.1/Fake
The Ruby scripts and batch files we are using now to manage the build environment are one of the things that I'm thinking need to be replaced sooner rather than later. We know we want something like Ruby Rake which uses Fan scripts to manage builds:
I'm thinking there is a new "fake" pod that defines a fake::Build class and maybe some specialized subclasses like BuildPod, and then you would create a "fake.fan" script in the top level of each of your modules. Need to do a lot more brainstorming on this one.
brian Sat 28 Oct 2006
I added the following methods to support the Fan props format:
Props are just a Str:Str map. This format will be used to handle environment variables, and also localization. The prop format is based on Java properties files, but uses UTF-8 and Fan style comments:
///* */(may be nested)