google`AppEngine file system intro

2.20: news.adda/co/google`AppEngine file system intro:
G'AppEngine`concepts:
. projects store objects in buckets
which are like folders but non-nestable;
and have names that are unique across
not just the project but all of g'storage .
. immutability applies only to objects
not filenames, [symbolic vs hard links].
Object names can contain
any combination less than 1024 bytes,
of Unicode characters (UTF-8 encoded)
including "/"
so that you can use old pathnames
while google sees the entire path as one filename,
as the only hierarchy is
(g'storage, some-bucket, some-pathname).
For most operations you can use either of
the following URLs to access an object:
storage.googleapis.com/≺bucket>/≺object>
≺bucket>.storage.googleapis.com/≺object>
www.googleapis.com/storage/v1beta2/b/≺bucket>/o/≺object>?alt=media (JSON API)

CP4E hero Bret Victor

9.8: news.adde/light table and bret victor:

. Bret Victor's video has a cp4e mission
and shows off the new tools he's built
that help us develope our creative ideas .

. amazing what he's done;
he has an IDE where you can click on any var,
and it turns into the widget needed to adjust it;
but then it's also
re-running your code after every change;
so, if your program generates a picture,
his scripts are custom GUI's for
painting particular classes of pictures
where you paint by both coding
and by adjusting code parameters
-- all by GUI! (as you do edits,
the page is sprouting widgets to help you).
. when you slide a for-loop var,
the program is re-running for every
value in the for-loop's change range
which is causing an animation effect
-- a new way to experiment with video .

. even more amazing,
this IDE creates a complete mapping
between the subpicture being drawn
and the line of code that drew it;
so clicking in the picture
causes the editor to highlight a line of code,
and conversely, selecting a line of code
highlights the subpictures it drew .

. now, speaking of animation,
the next thing needed for visualization
is to create trails for specific subpictures,
so that as you modify a parameter,
it immediately shows how that is affecting
the path of the trail .
. first he's pausing at the
end of the interesting time interval,
then he's using rewind to get to the
beginning of his time interval of interest;
and finally when he's adjusting parameters now,
for each new parameter change,
it's drawing a new trail specific to the
time interval of interest .

. why are there symbols in a schematic?
because it's the easiest way to pen them,
Victor notices ( and there's the icon effect
-- creating instant recall of the concept );
but now that schematics are in computers,
we should be using their dynamic expression:
so, in an electronics diagram,
we could replace the symbols with
little videos of the analog signals
that are generated at that symbol's node .

. likewise, computers can make coding so easy
that any one can do it;
indeed, it seems that the best coders
are just those who are best at
imagining a computer's working internals,
but we have the computer to do this for us,
so why don't we?!
. for example he shows another IDE,
this one being tuned for coding instead of drawing
in which the editor has 2 areas:
on one side is the code,
and on the other is a simulation of the code;
ie, the simulation has a list of all the locals
that are so far declared in your function,
-- and it does this in real time:
eg, as you write the function's header,
the simulation shows the parameters as undefined;
then you can modify the simulation
by instantiating any undefined variables
(so the assignment happens only in the simulation,
not your code), and then as you have code
assigning a complex expression to a var,
the simulation tries to eval that assignment;
and, this way you are testing as you code
-- every time you hit enter,
it's relaunching the build&run
for per-line-of-code testing (quick!).
. if you add a loop to your code,
then all the var's being affected by the loop
are placed in a matrix
with vars in the columns,
and iterations per row (or vice versa).

. he then gives us a history of people who
had a passion for using computers to
help people with making full use of their brains;
pointing out that this work is important because
people need these dynamic tools
to unleash their full human potential .
. he was especially impressed at
those who made computers child's play;
and reminded the audience's budding techies
that we can choose as our identity
to have a social conscience,
and not just a technical expertise .

pioneers of cp4e:
(computer programming 4 everybody)

# Larry "nomodes.com" Tesler:
. not just the developer of copy&paste
but the one realizing we could do better than
obstructive modal versions of copy&paste:
he recognized a wrong
that was unrecognized by the culture .

# Doug Engelbart -- enabling mankind:
. propent of realtime human-computer interaction
not just the inventor of the mouse:
he wanted to solve mankind's urgent problems with
computer-assisted knowledge workers .

# Alan Kay -- enabling children:
. everything he did for windows, menus, and oop,
was to enable children to be computer literate
to make them more enlightened adults!
. he studied those who studied how children think,
in order to help them use computers .
[. in 2006, Kay's Viewpoints Research Institute
was funded by USA's NSF for the proposal:
Steps Toward the Reinvention of Programming:
A compact and Practical Model of
Personal Computing as a Self-exploratorium [pdf]
(see comments of it:
. they critiqued him for bucking the trend of
taking advantage of cheaper hardware
by filling it with more features and bling;
but ironically, that attitude
still hadn't been able to provide all children
with a computer that would help them learn
-- children's computers need to be
as cheap as calculators;
but instead we insist on continuing to
code above the child's price point .]

# Richard Stallman -- freedomware:
. the king of fighting to change culture
for the good of mankind .

9.8: web: i-programmer.info`
Alex Armstrong 10 March 2012`
A Better Way To Program

This video will change the way
you think about programming.
The argument is clear and impressive
- it suggest that we really are building programs with
one hand tied behind our backs.
After you have watched the video
you will want the tools [that he has] demonstrated.

We often focus on programming languages
and think that we need a
better language to program better.
Bret Victor gave a talk that demonstrated
that this is probably only a
tiny part of the problem.
The key is probably interactivity.
Don't wait for a compile to complete
to see what effect your code has on things
- if you can see it in real time
then programming becomes much easier.
Currently we are programming with
one arm tied behind our backs
because the tools that we use
separate us from what we write and what happens.
Interactivity makes code understandable.
Moving on, the next idea is that
instead of reading code and understanding it,
seeing what the code does is understanding it.
Programmers can only understand their code by
pretending to be computers and running it in their heads.
As this video shows, this is incredibly inefficient
and, as we generally have a computer in front of us,
why not use it to help us understand the code?
...
if you watch just one video this year
make it this one.
Update:
See Light Table - a Realization of a New Way to Code

[ an implementation of Victor's idea .]
[ it was funded by a kickstarter page .]
You can now try Light Table
via the Light Table Playground!

9.8: web: Bret Victor
. Bret Victor's inspiring resume
and his many cool writings .
. Bret Victor`Inventing on Principle [vid]
from CUSEC 2012 (Canadian University
Software Engineering Conference)

-- a three-day event that brings together
undergraduate and post-graduate students
for learning, networking,
and sharing their passion for software.

9.8: web: chris-granger.com`
Light Table --a new IDE concept

Despite the dramatic shift toward
simplification in software interfaces,
the world of development tools
continues to shrink our workspace
with feature after feature
in every release.
Even with all of these things at our disposal,
we're stuck in a world of files
and forced organization
- why are we still looking all over the place
for the things we need when we're coding?
Why is everything just static text?

Bret Victor hinted at the idea that
we can do much better than we are now
- we can provide instant feedback,
we can show you how your changes affect a system.
And I discovered he was right.
...
 all of this culminates in the ability to see
 how values flow through our entire codebase.
 Here I find a bug where I wasn't passing x correctly.
 I type (greetings ["chris"])
 and immediately see all the values filled in
 not just for the current function
 but all the functions that it uses as well.

Light Table is based on a very simple idea:
we need a real work surface to code on,
not just an editor and a project explorer.
We need to be able to
move things around, keep clutter down,
and bring information to the foreground
in the places we need it most.

Light table is based on
a few guiding principles:
You should never have to look for documentation
Files are not the best representation of code,
just a convenient serialization.
Editors can be anywhere
and show you anything - not just text.
Trying is encouraged
- changes produce instantaneous results
We can shine some light on related bits of code

Docs everywhere
When you're looking at new code
it's extremely valuable to be able to
quickly see documentation left behind by the author.
Normally to do so you'd have to
navigate to the definition of the function,
but lightable ghosts this information in to the side.
Want to know what partial does?
Just put your cursor on top of it.
This makes sure you never have to worry about
forgetting things like argument order ever again.

. we should be able to search all our documentation
in place to quickly see what it is.
Don't remember what was in the noir.core namespace?
It's one ctrl-f away.

This is especially handy for finding
functions you may not even know exist
and seeing their docs right there.
No need to look at some other generated documentation.

Instant feedback
.  to try things out, we can do better
than lispers' REPL - we can do it
in place and instantaneously.
For example we can type in (3 + 4)
and immediately we are shown the result
- no ctrl-enter or anything else.

Light Table takes this idea as far as it can
and doesn't just show you variables to the side,
but actually shows you how the code is filled in.
This lets you see how values flow through
arbitrarily complex groups of functions.

This level of real-time evaluation and visualization
basically creates a real-time debugger,
allowing you to quickly try various inputs
and watch it flow through your code.
There's no faster way to catch bugs
than to watch your program work.

We built drafting tables for a reason
. desktop windows aren't a good abstraction
for what we do as software engineers .
Other engineers have large tables
where they can scatter around
drawings, tools, and other information .
A drafting table is a better abstraction:
We shouldn't need to limit ourselves
to a world where the smallest moveable unit
is a file - our code has much more
complex interactions that we can better see
when we can organize things conceptually.
. We saw an example of this with Code Bubbles,
but why can't we embed a running game ?
Then we can interrogate it,
and have our environment answer them for us.

[9.8:
. an image in the article at this point
shows a desktop where a folder full of files
is represented by a box
whose title is named after the folder
with file names inside the box .
. the right side has boxes of code;
so, for each function you inspect,
it also shows you called function`bodies .)
--
. this reminds of composite editing,
where the editor holds the entire desktop;
so, it serves as desktop layouts that can be
suspended and resumed as if a vmware .
. desktops and their windows
can be edited the same as
when an editor embeds images in text .
. the first compound docs I saw
were ms`office embedded objects:
you could mix & match Word's text columns,
Excel's spreadsheet windows, and various images .
. browsers have this feature (the embed tag);
but browsers are short on editing abilities,
and editors need to be integrated with the OS;
such that I can open a file,
and it unleashes a desktop of windows
all arranged in the way they were before .
. also, the layout editor needs to
control the border style of its windows;
eg, embedded graphics in text
should often have no border at all .
. a 1st class composite document
has everything we like about vmware,
but instead of windowing OS's
our compositing app is windowing apps .]

Code with a little illumination
There's no reason our tools can't
help us understand how things are organized .
In light mode, Light Table lets you
see what functions are called by
the one you're currently working on,
not just by highlighting ones in your code,
but by also showing you their code to the side.
We shouldn't have to constantly
navigate back and forth to see this .

Finally, all of this culminates
in the ability to see not just how
things I type into a scratch editor evaluate,
but how values flow through our entire codebase.
Here I find a bug where I wasn't passing x correctly.
I type (greetings ["chris"]) and immediately see
all the values filled in
not just for the current function
but all the functions that it uses as well.

What languages will it support?
. The first two are Javascript and Clojure,
.... we hit $300k! Python will be the
third language supported out of the gate.
. additionally,
new languages can happen through plugins.

Will it be open source?
. a firm believer in open source software
and open source technologies.
we can guarantee you that Light Table will be
built on top of the technologies that are
freely available to us today.
As such, we believe it only fair that
the core of Light Table
be open sourced once it is launched.
At some level, this is an experiment in
how open source and business can mix
- it will be educational for us all.

What's a license then?
. In order to download packaged distributions,
you'll need a license. Preliminarily,
we're thinking, for individuals,
licenses will be based on a model of:
"pay as much as you can of
what you believe it is worth".
. This gives everyone access to the tools
to help shape our future,
but also helps us stick around to
continue making the platform awesome.
We think what we build will be worth at least $50,
and so that's what we've used for our rewards.

Is it a standalone app?
. there's an instance of webkit as the UI layer
-- completely an implementation detail.
It will run locally on virtually any platform
and out of the gate will support
the big three (linux/mac/windows).

Can I script/extend it?
. It will be scriptable in Javascript
(and many other languages can be
translated into Javascript).
Ultimately the goal of the platform
is to be a highly extensible work surface
- even the initial core languages
will be written as plugins.
This allows us to build development interfaces
we haven't even imagined yet.

What about key bindings?
. by using the awesome CodeMirror editor,
this is something that is easily adapted.
If you're looking for a way to contribute,
help improve CodeMirror
and its emacs/vim plugins!
--[
CodeMirror is a JavaScript component
that provides a code editor in the browser.
When a mode is available for your language
[c, python, go, js, ...]
it will color your code,
and optionally help with indentation.
. rich programming API and a CSS theming
for customizing CodeMirror
and extending it with new functionality.
. it's used by Mergely which is a
powerful online diff and merge editor
(Browser-based differencing tool)
that highlights changes in text.
It can be embedded within your own Web application
to compare files, text, C, C++, Java,
HTML, XML, CSS, and javascript.]

How can I help in the meantime?
. The better CodeMirror is,
the better all internet editors can be!
Past that, help us spread the word.
The more money we get
the more people I can involve in the project,
the more languages we can support,
and the more powerful the entire platform.
There's tremendous potential
-- we haven't even scratched the surface yet!

About the Developer:
. helped design the future of Visual Studio,
and released numerous open source
libraries and frameworks.
. for Microsoft was the Program Manager for
the C# and VB IDE
-- countless hours behind a one way mirror
learning how people develop things.
Since then steeped in the world of
startups and OSS.
. worked with the guys at ReadyForZero
to build readyforzero.com,
created the Noir web framework,
built the SQL abstraction layer Korma,
and released a host of ClojureScript libraries
to make client side development a breeze
- many of which are now featured in
the canonical books for Clojure.
Even more recently,
built Bret Victor's live game editor
after watching his inspiring
"Inventing on Principle" presentation .

Light Table at news.ycombinator.com:

briantrice

One thing Light Table could pick up / learn
is the ability to scale as function set grows,
to gain a kind of fractal navigability.

--[. I think he's refering to the call tree idea
aside from the view's detail modes
(nodes-view vs thumbnails vs fullview)]
stcredzero/"I told you so!"

Smalltalkers have been doing [LightTable]
--[the right thing]-- since the 80's
(If only we could have communicated
about this as well as Mr. Granger).
The first and the last points [under Also:]
were satisfied by lightning-fast searches of
"senders" and "implementers" .
1980's smalltalk:
- Smallest unit of code is the function.
- Able to get instant feedback on code changes.
- Multiple editors with just one function in it.
Show code in an "area of concern" not just in a file.
- The coding environment can show also
results, app windows, graphics, other tools.
- Can save the configuration of the above.
Also:
- You should never have to look for documentation
- Files are not the best representation of code,
 just a convenient serialization.
- Editors can be anywhere
and show you anything - not just text.
- changes produce instaneous results
- We can shine some light on related bits of code .

shykes:

. Dan Ingalls, the father of Smalltalk,
has picked up the baton again,
this time using Javascript.
Check out the MIT-licensed Lively Kernel
-- a new approach to Web programming
. the live demo at JSConf was jaw-dropping;
completely in line with the Smalltalk legacy .
It provides a complete platform for Web applications,
including dynamic graphics, network access,
and development tools.

Field (programming environment)
. embraces most (if not all)
of Light Table's principles.
--
As always, the multi-media programming environments
are miles ahead and nobody knows about them.
Field[by The OpenEnded Group] is amazing.
{Max/MSP, Pd, ...} are a different paradigm altogether,
but have had live editing, documentation a click away, etc
and have been in heavy use for 20+ years.

list of multi-media programming environments?
. the big names are Max/MSP, Pure Data,
vvvv, QuartzComposer, SuperCollider,
ChucK, Processing, openFrameworks,
Cinder, and Field[The OpenEnded Group].
But there are many more smaller projects
such as Lubyk, Overtone, LuaAV,
Faust, Plask, Impromptu and Fluxus.
I also want to plug NoFlo, which is a
'flow-based programming' library for node.js,
which integrates with a visual editor.


gfodor, vdm, nickik:
recommend some reading materials?
Victor's writings
The Design of Design (see part 4)
simplicity’s virtues over easiness’
Alan Kay`Programming and Scaling [vid]
Viewpoints Research Institute
Mindstorms: Children, Computers, And Powerful Ideas
PLATO Learning System [vid]
udacity -- cheap edu
coursera -- cheap edu
khanacadamy -- free videos

libraries and namespaces

6.14: adda/library/authors include system, app, client:

. Python has 2 libraries to choose from:
standard and local .
. Ada has one library with any number of modules,
including standard.package .
. instead of ada's one library,
there should be 3 libraries, one for each author:
system-authored -- the standard modules;
app-authored -- the software developer;
client-authored -- the user of the app .

. libraries can be specified by the app author,
(system is adda/aModule, local is ~/aModule )
but specifying this is not necessary because
the app's local library is always checked first;
ie, if an app author wants to use a system module
they simply abstain from giving any local modules
the same name as the needed system module .

. module providers can define
what other authors they want used
and in what order .
. notice that while many commercial wares
are arranged by author,
many openwares are arranged by project;
ie, each project represents an author collective;
but these collectives then have branches
which might represent either author subsets
or target-specific variations;
so, the typical explicit local path will be:
~/myProject/myBranch/myModule .

6.15:
. the client's library can have subfolders for
each of the authors: system and each app .
. the compiler always gives the client the final say,
so that if the users want to modify (system/x.pkg)
they write their own in (client/system/x.pkg).
. if the author requires that they not be modified
then a commercial version of the compiler
would alert the user that their modification
is being ignored due to contractual obligations .
. in the open-only version of the compiler,
the user would be unable to install commercial wares .

6.18: adda/library/hierarchical librarians:
. we could also have the idea of hierarchical librarians;
ie, just as the typical librarian is local to the file system,
rather than applying to the entire local network
or to the entire internet,
so also, a librarian could be local to a folder .
6.19:
x : dir-name/type-name
. what was the library structure defined by ? ...

6.14: adda/type/record expressions vs literals:

. being required to statically type vars
is not a loss of freedom because
we can declare a var to be tall.type,
which means it may include any type
(tall typings are like tall tales,
leading t'all sorts of things ...).

. what should the import syntax be?
my first idea was that explicit importing was mostly unneeded,
because by typing var's,
we implicitly import that type's module;
but there are other types of modules to reuse .

. think of the orthogality:
when defining var's in a name space,
these are actually fields in a record literal;
. just as data types may define both literal values
and expressions that return values;
so too we should be able to define record structures
with either literals or expressions .
. ada uses {with, use} for expressing this .

. a situation similar to importing is inheritance
so importing should have the same syntax .
. a recent proposal for such syntax was
(3.23: adda/oop/syntax/sections for use, is, has).
. it suggested 3 new keywords:
# use:
. for an interface to import a module;
they may refer to types other than self
that are not in the top-level library .
[6.15:
. here's all the places a type's name can get reused:
app's pkg, pkg's of other authors being imported
wanting a system type
even though app has redefined that type name
in one of its own local modules .]
# is:
. for supertypes,
establishing type compatibility .
# has:
. for listing the type's known subtypes;
eg, number.type has all of these subtypes:
int, real, quotient, complex, modular .

. I thought a good word for "(import) was "(has),
but if possible I should make sure that
the keywords have similar meanings
when used by inheritance and namespace definition .

7.2: todo:
. I need to show the diff's and similarities
of inheritance to namespace definitions .

6.15: adda/library/anonymous record declarations:

. why not do imports by declaring records globally,
and then instantiating records?
and instead of (with; use),
do an anonymous instantiation;
ie, instead of (x.myrec), say  (.myrec)?
but if we have multiple anonymous record declarations
with conflicting component names,
we have no way to resolve the conflict
because we have no root name to specify .
[6.19:
. we could use the type name as a root,
and use either record instances or rec'types .
. rename is done like this (x: mypkg)
while using original name is (: mypkg)
and if conflict use (mypkg.component).
. anything on the right side of colon must be a
library item, either an instance or a type .
. might be easier on the reader's eye if we
always required renaming when importing rec'instance .

. should we always have an implicit ada'use in force
for if a naming contention exists ?
here's the reason ada'use is optional:
it is filling the name space;
and, these included names can't be redefined now;
better to use ada'use the way ada uses it .]

. Ada's packages are like record instances
-- in contrast to record types;
Ada'with(package) allows the instance to be
visible to the current scope .
. packages in the Ada library may include variables
(this is how Ada can define global variables).
. by being instances instead of record types,
the included variables are being shared by
every process that includes such a package,
ie, a global record instance .

. subrograms are types not instances;
when we have a pointer to a function
what we have is a constant template
which can be shared by numerous
function activation records,
just as numerous record instances
share the metadata of a record type
that is in control of record instance formatting .
. thus, a function activation requires a pair:
(the name of the subprogram providing the template,
and the address of an activation record);
when we speak of a process,
this pair is what we're refering to;
(6.17:
but when concurrency is considered,
then a process implies a triple:
the 3rd component of this triple is a
thread of execution:
either the id of the processor it is using,
or a task mgt record
for controlling a slice of the processor's time ).

. global variable instances can be confusingly shared by
many authors' processes;
so, a global variable should be registering
which processes are using it,
and be able to tell us which processes have been involved;
likewise, any subprogram that can
spawn tasks which can share its local var's,
creates a situation where processes share a var
but this is not so confusing because
it doesn't involve sharing among various authors .
[6.16:
. the way globals are shared by various authors
can also be happening locally,
if we can import a package that expects
the eviron to provide a sharable var .
[6.18:
. but maybe this should not be happening;
if you want an import to use your locals
it should exist as parameterized record type,
so then a parameter used during record instantiation
is passed the address of locals it can use .
... or how about this:
. when a type is instantiated by a client,
in addition to allocating an instance,
it also gets some sharing space in client
which the type mgt can use for keeping
meta info or parameters
that are relevant to just a particular client's set of
a particular type's instances .
. this new space would be similar to class var's,
except that instead of being shared by all members of the class,
they would be shared only by those members
that were owned by a particular client
ie, contained in a particular subprogram activation record
or a declare block .
. so then, if type mgt's can do this,
instantiated records could also .]

. other confusions with what's global include
# the internet is the top-most global,
# one's local network is global to a file system .

. we can think of global var's as
implicitely inheriting from registering
(no process can access the registering type
without getting registered).
. if we want registering behavior for a local
we must explicitly have it inherit from registering .

. my initial concern with vars being shared
could only happen because the author put the var there,
but there could still be surprises among an author's subprograms
because the author's client can choose to
run more than one of the author's sub's at a time .
. an imported sub' should be able to
declare a non-local var as a dependency
in order to have symmetry with the idea that
subs can access non-local vars;
and,
that feature should be orthogonal to
the feature of a sub being reusable .]

tags, link-trees, and file-trees

7.3: 7.30: adde/tags, link-trees, and file-trees:
. how to integrate tags with folder systems?
placing a file in a folder is tagging it;
 a hierarchy is a tag with segments;
ie, each path name is one tag .
. while a file can be in only one folder,
it can be assigned to many tags .

. tags can be thought of as
a list of links to its members;
and, equivalently, as attributes of a file:
each file or file link can list all the tags
to which it is a member,
just as it can tell the folder path it's in .

link-trees vs file-trees:
. a file-tree is the usual folder tree,
it contains actual files rather than links;
so, a file can be a member of only one file-tree .
. the link-tree is like a file-tree
except it contains only links to files
rather than actual files;
thus, a file can belong to many link-trees,
and may be in many places
within the same link-tree .
7.30:
. the main idea for these distinctions
is that file-trees are low-level concerns;
the only reason they need to be accessed
is when the space limits require
deletions or archiving .
. most file system operations
are concerned only with organizing files,
not managing limited space,
and each activity should have its own
customized view of the file system;
so, most file accesses should be done
through link-trees .
. tags can be applied to either files or links,
depending on the tag's scope:
tags on files are global;
tags on links apply only to
a specific link-tree;
ie, each link-tree has its own set of tags:
both the ones induced by the global tags
belonging to files it's linking to,
and the tags specified by the
user of the link-tree .

editor's uncluttered ascii mode

12.26: adde/ascii mode:
news:
"( Many developers want ASCII-based editors,
in which case the syntactic clutter of
varying annotations
can rapidly become overwhelming. )
--
. adde makes it easier to use graphics
and other coded features,
by folding in code like html does,
but, for the sake of ascii tools,
it also needs to optionally provide
a file system that removes clutter
by putting the code into
files separate from the ascii .
. after modification by a foreign editor
the adde editor needs a way to know
how to merge the code with the text .
. for this it can use ascii bookmarks
which follow the head-body pattern:
their title indicates what they represent
and they have a pointer into the code file
showing where the body of code is
that implements that graphic .

. if adde finds a modified ascii file,
it checks for missing bookmarks
in order to delete the corresponding bodies .

. the code file is ascii too, of course,
but none of the words are about content
rather they give details of graphics .
. a foreign editor can see
the body of any given bookmark
by searching for the bookmark's pointer
within the code file .

. assuming that any given project folder
will have numerous text files
that may all need ascii-code separation,
one simple way to manage this separation
is to put all the code files
in a subfolder named code;
so that they can have
exactly the same name as the
ascii files they belong to;
so, if working on file: ./x,
--[the ./ means current folder ]--
then a search in ./code/x
will find the body of a bookmark .

filesystem as intranet of vol's and slots

10.13: mis.adda/syntax/directory as pointer model:

. if the ptr syntax is modeled after files,

then you bump into the confusion that

although folders are impl'd as pointers,

they have {copy, cut, paste} operations

that are acting as if they were containers

just like arrays, or records .

10.17: adda/syntax/volumes as a domain class:

. to unify the files systems of the pc and unix,

removables (type"volume) should be considered to be

internet nodes of domain"vol .

. a user has, both a current vol

and a current directory within each vol .

[typical pc behavior?]

10.26: adde/fs/entity and its id:

. another dimension of file id

is the volume the file is on;

because, an owner can write to several volumes

at the same time

so is not unique .

in fact, the vol'mgt is then

both the unique and direct creator;

but, consider every file must be sync'd across multiple val's

so, like git,

the unit of creation should be considered to be

the project or db, not the file .

10.27:

. a file can be uniquely identified by

(vol name * create`time * serial#)

. the serial# is needed if the vol can create a

set of files at one time,

or if the system clock is not giving accuracy to put

every file-create in its own time slice .

content vs container:

. the create time for the file

differs from that of the contents .

10.27: adda/syntax/url` slots vs vol's:

. the url domains: {vol, slot, drive} are for local content

that is reachable by a removable disk .

. drives are plugged into slots,

and volumes (eg, disks) are plugged into drives .

11.5: adda/syntax/url/filename recursively like site name:

. suppose net syntax is recursive,

so a file can be another whole net system:

//x.com/y.com

. the first idea to flesh out is

how it could make sense to use dot notation for files

the way sites do:

subj.name.type

. when they had www.x.type,

the www (front-dotted name) meant an entity

had a library fit for world-wide webbing

. another view is that

www refers to the default app;

eg, www.google.com means google's main service (search);

but then there's other services

mail, picasa, knol, code, etc .

. sites are {processors, entities} offering various services,

so in the case of locally,

a site-style name could be used for users:

eg, dev.addn.user would be a file-system dedicated to

addn's dev'ing .

11.12: adda/syntax/url/filenames like sitenames:

. when filenames have types like websites domains,

that means they are processors,

and their domains have similar meanings:

.com is closedware,

.org is openware,

.edu is knowledgebase or expert system,

.mil is security services,

.gov is os daemons .

12.1: adda/syntax/url/the register domain:

. an url naming system should represent all address spaces as

internet nodes;

eg, registers are separate address space

and so they should have their own website in the reg domain .

. the url's protocol is really not needed;

it is indicating the communications type

and is esp'ly irrelevant when the os is the same everywhere;

but, even with a variety of os's

it seems the usual is https, and that should be the default .

12.1: adda/syntax/url/the internet root as module symbol:

. a corollary of every address space getting a web node address,

is that the internet root symbol (//)

is the prefix that identifies concurrent objects:

eg, task instances, and sharable (stateless) library units .

. additionally, (//) identifies a pointer to filesystem

such that you can have access to multiple filesytems,

each having a current working directory;

eg, //destination`= //source .

whereas, //source/ (with the (/) appended)

would indicate the root directory rather than the current working directory .

. the domain name is a type name,

so then name.domain (where the type.mark happens to be a domain name)

would declare name to be a filesystem .

. once you know that a symbol is a domain-typed obj,

when is the syntax (//name) needed ?

for recursive use of domain names,

it shows when the symbol at top level

-- the level of the internet or the system

(some of the domain names are reserved for system components) .

type a/.//?

. the // is part of address literal

so not a type name as its ambiguous

. just as (/) means ptr concept

(//) symbolizes the a modular (or removable) filesystem

a separate address space,

. every tree var is //a.tree/...

adda lib consists of nodes in the adda domain //a.adda/