At present the plugins don't hyperlink correctly because the data
format is wrong. They're being fed the server_config.cfg file
which has stuff like:
# Configuration file for webapp
delay=0.05
port=8080
server_root=.
document_root=$server_root/html
C_PATH =
$INSTALL_ROOT/lib/rtl,/usr/local/include,/usr/include,/usr/include/c++/4.6.2,/usr/local/include,/usr/include,/usr/include/c++/4.2.1,/usr/include/c++/4.2.1/x86_64-apple-darwin10,/usr/include/c++/4.4.3,/usr/include/c++/4.4.3/x86_64-linux-gnu,/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
FLX_PATH=$INSTALL_ROOT/lib
FDOC_PATH=$DOCS,$DOCS/doc,$DOCS/web
FLX_PKGCONFIG=$INSTALL_ROOT/config
DB = $server_root/db/wiki.db
in it. The plugins require
C_PATH += /usr/include/c++/4.2.1
C_PATH += /usr/include/c++/4.2.1/x86_64-apple-darwin10
C_PATH += /usr/include/c++/4.4.3
C_PATH += /usr/include/c++/4.4.3/x86_64-linux-gnu
C_PATH += /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
instead. Although the wiki config does try to build a native Felix
representation of this data, it's no use to the plugins, which require
a string they parse themselves.
The string format is "cheap untyped and unsafe polymorphism".
Plugins have trouble with static data types (it can be done but
it isn't quite so easy to say, pass a list, we have to note there's
no type checking because the interfaces are all extern "C"
instead of C++).
Passing a string has the advantage that it doesn't require any knowledge
of what plugins exist. This layout:
extension flx -> flx2html::xlat_felix
extension flxh -> flx2html::xlat_felix
extension c -> cpp2html::xlat_cpp
extension cpp -> cpp2html::xlat_cpp
extension cxx -> cpp2html::xlat_cpp
extension h -> cpp2html::xlat_cpp
extension hpp -> cpp2html::xlat_cpp
extension fpc -> fdoc2html::xlat_fpc
extension fdoc -> fdoc2html::xlat_fdoc
extension ml -> ocaml2html::xlat_ocaml
extension mli -> ocaml2html::xlat_ocaml
extension py -> py2html::xlat_py
is not currently properly used by my webserver or the wiki: the file
extension is just ignored. Both programs have hard coded mappings
from the file extensions to inbuilt handlers which dispatch to fixed
plugins to do the colourisation. The plugins themselves (felix and
fdoc plugins) also do this.
None of this is optimal, but for the moment the hyperlinking problem
needs to be fixed so the wiki displays dispatch properly to
library files, etc.
I am going to change more things slowly regarding configuration.
For example, the initial build system calculates a C compiler.
The way to use this is hard coded into plat/config.flx,
which is linked to by flx so it can compile the C++ generated
by flxg.
But the right way to do this is to use flx_pkgconfig to get the
required fields from a database. This allows you to just point
to a different compiler package e.g to switch from gcc to
clang without having to recompile flx.
Another way to do it .. is to point flx at a plugin which has the
appropriate pre-compiled flx code. This approach is needed
when "string parameters" aren't enough (eg colourising code).
One thing to look at now is that since we have "OO" in Felix
by way of interfaces and objects, and we can have records,
of anything (eg config parameters) with statically fixed
fields, it's time to consider a dictionary type.
It is possible to do this: given a Python or JS type of dictionary,
string to string, it's possible to "automagically" populate a
record using it. In other words you have a record type:
interface X {
mydata: string;
yourdata: string;
};
and you have a dictionary:
var d = dict[string, string] (list
("mydaya","value","yourdata":"other". ...);
var x : X = object X() end;
populate x from d;
Non-trivial, but the compiler knows the names of the fields in the
object, and what type they are, so it can easily load up the record
from the dictionary (well it's a lot of hackery in Scheme action codes
in the parser but it's all doable in user space, no mods to the
compiler required).
Of course we HAVE dictionaries already: JudySL arrays map
(null terminated) strings to pointers. They're just not convenient
to use (no iterators, no simple syntax for setting values etc).
but we can just copy Python there until we have a suitable
typeclass. We can also use STL map for string/string
(though there's probably no point since Judy is sure to be
10x faster).
The important thing here is to provide a dynamic <--> static
typing bridge.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
