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.
David
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:
David,
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 ;)
-Martin
On Mon, Feb 27, 2012 at 3:54 AM, David Girle<davidgi...@gmail.com> wrote:
Take a look at the page:
http://piumarta.com/software/maru/
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.
David
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
