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
