On 2/27/2012 1:27 PM, David Girle wrote:
I am interested in the embedded uses of Maru, so I cannot comment on
"how to get from here to a Frank-like GUI".  I have no idea how many
others on this list are interested in the Internet of Things (IoT),
but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
will bring up a connected, smart sensor system, rather than the 20kLOC
target VPRI have in mind for a programming system.


IoT: had to look it up, but it sounds like something which could easily turn very cyber-punky or end up being abused in some sort of dystopic future scenario. accidentally touch some random object and suddenly the person has a price on their head and police jumping in through their window armed with automatic weapons or something...

and escape is difficult as doors will automatically lock on their approach, and random objects will fly into their path as they try to make a run for it, ... (because reality itself has something akin to the "Radiant AI" system from Oblivion or Fallout 3).

(well, ok, not that I expect something like this would necessarily happen... or that the idea is necessarily a bad idea...).

granted, as for kloc:
code has to go somewhere, I don't think 5 kloc is going to work.

looking at the Maru stuff from earlier, I would have to check, but I suspect it may already go over that budget (by quickly looking at a few files and adding up the line counts).

admittedly, I don't as much believe in the tiny kloc goal, since as-is, getting a complete modern computing system down into a few Mloc would already be a bit of an achievement (vs, say, a 14 Mloc kernel running a 4 Mloc web browser, on a probably 10 Mloc GUI framework, all being compiled by a 5 Mloc C compiler, add another 1 Mloc if one wants a 3D engine, ...).

yes, one can make systems much smaller, but typically at a cost in terms of functionality, like one has a small OS kernel that only run on a single hardware configuration, a compiler that only supports a single target, a web browser which only supports very minimal functionality, ...

absent a clearly different strategy (what the VPRI people seem to be pursuing), the above outcome would not be desirable, and it is generally much more desirable to have a feature-rich system, even if potentially the LOC counts are far beyond the ability of any given person to understand (and if the total LOC for the system, is likely, *huge*...).

very course estimates:
a Linux installation DVD is 3.5 GB;
assume for a moment that nearly all of this is (likely) compressed program-binary code, and assuming that code tends to compress to approx 1/4 its original size with Deflate;
so, probably 14GB of binary code;
my approx 1Mloc app compiles to about 16.5 MB of DLLs;
assuming everything else holds (and the basic assumptions are correct), this would work out to ~ 849 Mloc.

(a more realistic estimate would need to find how much is program code vs data files, and maybe find a better estimate of the binary-size to source-LOC mapping).

granted, there is probably a lot of redundancy which could likely be eliminated, and if one assumes it is a layered tower strategy (a large number of rings, with each layer "factoring out" most of what resides above it), then likely a significant reduction would be possible.

the problem is, one is still likely to have an initially fairly large "wind up time", so ultimately the resulting system, is still likely to be "pretty damn large" (assuming it can do everything a modern OS does, and more, it is still likely to be probably well into the Mloc range).

but, I could always be wrong here...

On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan<martino...@gmail.com>  wrote:

Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
files. There are also ".k"  files, which I don't know how they differ from
those, except that ".k" files are called with "./eval filename.k" while ".l"
files are called with "./eval repl.l filename.l" where "filename" is the
name of the file. Both kinds seem to be made of Maru code.

I still don't know how to go from here to a Frank-like GUI. I'm reading
other replies which seem to point that way. All tips are welcome ;)


On Mon, Feb 27, 2012 at 3:54 AM, David Girle<davidgi...@gmail.com>  wrote:
Take a look at the page:


it has the original version you have + current.
There is a short readme in the current version with some examples that
will get you going.


fonc mailing list

fonc mailing list

fonc mailing list

Reply via email to