Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
The problem with fixing shortcuts in file-systems, and with links and with names and with files in filesystems in general, is that the intention of the link, and even of a filename is not clear. For a simple example, compare a jpeg of your cat to a configuration file, e.g. /etc/passwd. It is silly to keep multiple copies of the jpeg of your cat in multiple locations on your hard drive just because you use it as your desktop wallpaper, have it in a slideshow, have referenced it in a newsletter, etc. but if you move or rename the file you would prefer that all these references to it don't suddenly break. In this case you might say that your intention is to refer to -this- file, regardless of name or location. Even an updated picture is not the same picture. Links to this file are perhaps intended to be links to this specific image. On the other hand, your /etc/passwd file tracks the users of your computer. When you update the file to change your password you don't want the system to keep referring to the old file. When you copy the file elsewhere for backups you don't want the system to go looking in the new location instead of the old location. In this case the intention is to refer to -any- file that is found in -this- location. Links to this file are intended to be links to this location. An interesting approach is to separate the naming concern from the content concern. One project is doing exactly this: http://camlistore.org (Content-Addressable Multi-Layer Indexed Storage.) The contents of files are stored as blobs and are addressed by the hash of their contents. Those hashes are referred to by claims, which are similar to the filenames and directories and links of a conventional file system. A natural consequence of this system is that de-duplication is built in and replication is simple. It has not been designed to be suitable for a high-performance file system though. Chuck On Oct 7, 2014, at 7:42 AM, Fernando Cacciola wrote: > On Tue, Oct 7, 2014 at 11:29 AM, Fernando Cacciola > wrote: > > I do realise of course that maintaining a gigantic master index of all files > is not applicable to the real world, but nonetheless I think the general form > of the solution (split identity from location) is worth being considered. > > > OTOH, it just ocurred to me that this can be made to scale to the real world > in the following way: > > A file could be formally classified a standalone or multiply-referenced. > A standalone file would be one which doesn't have an entry in the master > index. > A multiply-referenced file would be listed in the master index, given a > unique id and mapped to its current location. > > When you create a new link, the file is given a unique id, added to the > master index and the link is associated to the target's id. > The master index can even have a reference count allowing the file to > transition to standalone state when the last link is removed. > > This way the master index size is kept bounded by the number of effective > links in the file system. > > > Best > > -- > Fernando Cacciola > SciSoft Consulting, Founder > http://www.scisoft-consulting.com > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Project Oberon - The Design of an Operating System, a Compiler, and a Computer (2013 edition)
What I think is awesome is that after 30 years Dr. Wirth found some more things to take out of the language. I will certainly buy that book if/when it comes out in hardback. I have an earlier edition. I am tempted to get an FPGA just so I can run his Circuits-on-up Oberon OS. Chuck On Dec 3, 2013, at 9:51 AM, Erik Terpstra wrote: > http://www.inf.ethz.ch/personal/wirth/ProjectOberon/ > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] yet another meta compiler compiler
C? Where? I do admit to using Python for semantic productions. Python is terse and it was helpful to be able to pass tuples around. That said, I do not think that C is bad. One nice thing about C is its very lack of a helpful runtime. its up to you to supply that however you want. That is of course also its drawback. I think Maru is awesome, I'm still wrapping my head around COLAs. Every language is literate when embedded in a versatile markup… Thank you for taking a look and sharing your observations. Perhaps one day I will finish this book and give it a title. That is my intention, but you know about intentions... Meanwhile, Best wishes, Chuck On Feb 9, 2013, at 11:27 AM, Kjell Godo wrote: > What will this book be called? I would like to get one when it comes out. > > Why do you always start with C? Why not start with a higher language > like Smalltalk? You could compile ByteArrays that could then run > fast. Wouldn't it be more self documenting? You would have access to > all the Smalltalk resources. > > Because C is the portable assembler. > Because C has better access to all of the OS and all other languages. > By starting with C you leverage the C compiler. > You would have to write a C compiler in Smalltalk to get the same thing. > > I am writing BorgLisp in Smalltalk which is supposed to asimilate all > other computer languages into itself as dialects of lisp. Like > Clojure asimilates Java into itself. Like Cola was a combination of > Lisp and Smalltalk and C. > > I have one dialect of Lisp in BorgLisp so far and a source level > stepping debugger that can handle macros( it should ). It's written > in Dolphin Smalltalk but I would like to port it over to Pharo or > VisualWorks. If I tried to do the same thing in C I don't think I > could. > > Please explain why starting with C is better than this. > > Is there a debugger for C that is as good as the one in Smalltalk? > Do you use Test Driven Development as a way to get around not having a > debugger? > What programming environment do you use? > > I look at Maru and there are absolutely no comments in there. > A litterate version of Maru would be way too cool to ever actually > happen in this cursed universe we live in. I hope Maru is what I'm > talking about but I can't remember if it is or not. > > I hope you write this book with the literate meta compiler compiler in it. > > I hope I get my hands on it. I wish Maru was literate. > > Now what Favorite shall I put this link under so that I might have > some chance of ever seeing it again. I suppose my Git account would > be a good place to do that. But I don't Git over there that much. > > If I seem scattered maybe it's because I am a high functioning autistic. > > He said. > > On Fri, Feb 8, 2013 at 8:08 PM, Charles Perkins wrote: >> Thank you, Alan! >> >> That means quite a bit to me. >> >> I was so looking forward to a good pillage. Ah well… to follow your metaphor >> (a kinder one and more inclusive to be sure) I am most appreciative of the >> generous sharing of seeds going on around here. >> >> Chuck >> >> On Feb 8, 2013, at 5:42 PM, Alan Kay wrote: >> >> Looks nice to me! >> >> But no ivory towers around to pillage. (However planting a few seeds is >> almost always a good idea) >> >> Cheers, >> >> Alan >> >> >> >> From: Charles Perkins >> To: Fundamentals of New Computing >> Sent: Friday, February 8, 2013 3:52 PM >> Subject: [fonc] yet another meta compiler compiler >> >> While we're all waiting for the next STEP report I thought I'd share >> something I've been working on, inspired by O'Meta and by the Meta-II paper >> and by the discussions on this list from November. >> >> I've written up the construction of a parser generator and compiler compiler >> here: >> https://github.com/charlesap/ibnf/blob/master/SyntaxChapter.pdf?raw=true >> >> The source code can be had here: https://github.com/charlesap/ibnf >> >> Don't be fooled by the footnotes and references, this is a piece of outsider >> literature. I am a barbarian come to pillage the ivory tower. Yarr. >> >> Chuck >> ___ >> 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 >> > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] yet another meta compiler compiler
Thank you, Alan! That means quite a bit to me. I was so looking forward to a good pillage. Ah well… to follow your metaphor (a kinder one and more inclusive to be sure) I am most appreciative of the generous sharing of seeds going on around here. Chuck On Feb 8, 2013, at 5:42 PM, Alan Kay wrote: > Looks nice to me! > > But no ivory towers around to pillage. (However planting a few seeds is > almost always a good idea) > > Cheers, > > Alan > > > From: Charles Perkins > To: Fundamentals of New Computing > Sent: Friday, February 8, 2013 3:52 PM > Subject: [fonc] yet another meta compiler compiler > > While we're all waiting for the next STEP report I thought I'd share > something I've been working on, inspired by O'Meta and by the Meta-II paper > and by the discussions on this list from November. > > I've written up the construction of a parser generator and compiler compiler > here: https://github.com/charlesap/ibnf/blob/master/SyntaxChapter.pdf?raw=true > > The source code can be had here: https://github.com/charlesap/ibnf > > Don't be fooled by the footnotes and references, this is a piece of outsider > literature. I am a barbarian come to pillage the ivory tower. Yarr. > > Chuck > ___ > 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
Re: [fonc] yet another meta compiler compiler
Er… Hmm… About that…
In the (missing) Chapter 1 I attempt to illustrate building a computation model
using a declarative and incremental programming language. Towards the end of
that effort I realized I really needed an implementation of the language.
I really like Alessandro's work but when I saw the Meta II paper I saw the way
I wanted to do it in at least this first implementation.
A proper conclusion to Chapter 2 would come in three parts: implement in the
metacompiler (e.g. ibnf/six) a compiler for a minimal but general purpose
language, then b) reimplement the semantics for the language in its own self,
then c) reimplement the semantics for the metacompiler in that language. At
that point a self-sustaining development environment would be established. If
each of a, b and c can be done in 10 pages or so of literate programming text,
I think that would be pretty cool. It would be especially cool if at that point
it was easy to extend the system to integrate the source code and programming
styles of other systems.
Where there are two chapters there are sure to be more. I would like to
continue with an operating system kernel or two, networking, graphics, text
processing and the manipulation and distributed storage of relational data.
Wirth and Gutknect's Project Oberon is my inspiration for the project and STEPs
shows another way to build such a system. My own way would of course be a third
path to the peak of the same mountain of a self-sustaining computing system,
succinctly and fully described, useful for every-day tasks. Its a Quixotic
quest but I think the best quests are.
Thanks for taking a look!
Chuck
On Feb 8, 2013, at 4:48 PM, Matthew Retchin wrote:
> Where are the other chapters and what is the book about?
>
> On Fri, Feb 8, 2013 at 6:52 PM, Charles Perkins wrote:
> While we're all waiting for the next STEP report I thought I'd share
> something I've been working on, inspired by O'Meta and by the Meta-II paper
> and by the discussions on this list from November.
>
> I've written up the construction of a parser generator and compiler compiler
> here: https://github.com/charlesap/ibnf/blob/master/SyntaxChapter.pdf?raw=true
>
> The source code can be had here: https://github.com/charlesap/ibnf
>
> Don't be fooled by the footnotes and references, this is a piece of outsider
> literature. I am a barbarian come to pillage the ivory tower. Yarr.
>
> Chuck
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
>
> --
> (display "hello world") ; Scheme
> console.log("hello world"); // JavaScript
> ___
> 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] yet another meta compiler compiler
While we're all waiting for the next STEP report I thought I'd share something I've been working on, inspired by O'Meta and by the Meta-II paper and by the discussions on this list from November. I've written up the construction of a parser generator and compiler compiler here: https://github.com/charlesap/ibnf/blob/master/SyntaxChapter.pdf?raw=true The source code can be had here: https://github.com/charlesap/ibnf Don't be fooled by the footnotes and references, this is a piece of outsider literature. I am a barbarian come to pillage the ivory tower. Yarr. Chuck ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Hello everyone. I think of the code size reduction like this: A book of logarithm tables may be hundreds of pages in length and yet the equation producing the numbers can fit on one line. VPRI is exploring "runnable math" and is seeking key equations from which the functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced. It's not about code compression, its about functionality expansion. I also like to think of programming systems as bicycles, with levels of abstraction in the system as gears -- and shifting gears in todays programming systems is clunky. It would be nice to have a continuously variable transmission. Chuck On Feb 27, 2012, at 2:20 PM, BGB wrote: > 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 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. >>>
Re: [fonc] [S3] S3 recordings available online
awesome! On May 21, 2008, at 4:20 AM, Robert Hirschfeld wrote: Hi -- Video recordings of all talks given at the S3 Workshop on Self- sustaining Systems (held May 15-16 at the Hasso-Plattner-Institute in Potsdam, Germany) are available online via the tele-TASK system at http://www.swa.hpi.uni-potsdam.de/s3/program/. Best, Robert -- Robert Hirschfeld [EMAIL PROTECTED] www.hirschfeld.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
