MS`Portable Class Libraries

10.2: news.adda/MS`Portable Class Libraries:

Windows 8 programming model is like Xamarin,
[ where you write your apps entirely in C#,
and can run the resulting code on many platforms:
iOS, Android, Windows and Mac.]-12.8
. MS does this with Portable Class Libraries (PCL's)
which are subprograms that can be used anywhere
by attaching to whatever gui is on the current device
(supporting device-specific user interfaces).
PCLs let you wrap common code into a library,
ready for use by various gui's .

12.8: adda gui access is based on similar idea:

"( subprograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .)

10.2: 12.8:
. rather than having a subprogram export gui interactions
they are generating output like html
meant for describing what to display
but instead of being text a human can understand
it is encoded for quick access by other subprograms
including the human user's interaction agent
which builds a gui like html does .
. all native data types,
from which all other data types are composed,
have a gui presentation .
for instance, a tuple data type
is naturally represented as a dialog window,
and dialogs are then nestable like tuples can be .

model-view and composite tech

[thought I blogged this 9.2, but found as draft;
then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:

"( Potel questioned the need for the MVC's Controller;
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.).

. after reading that, I wrote this:

. I didn't get mvc either, and promptly redefined it:
subrograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .]

signaling in gui systems

8.12: adda/cstr/signals/signaling in gui systems:
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
gui-optimized signals,
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .

gui notification systems

6.4: adda/gui notification systems:

[. the original version of the gui pointer,
is a sort of additional type:
x.gui.t -- x is a gui pointer to type t .
. that way, you could pass x around,
and all type mgts then know
that in addition to performing the requested operation,
they should also be notifying the gui system
if the operation entailed a modification .
. the point is to be like QT's signaling system:
what is special about a gui'd obj
is that any modification triggers a signal to the
notification center,
which keeps a list of things to do in response .
. my revision of QT's idea was to
make gui notification a special case
so that instead of giving every object
the ability to emit notifications,
we are establishing a relationship directly with gui mgt
rather than going through a notification system .
. the gui type is an obj header that all type mgt's understand,
and it has any additional info that might be needed
in order to identify an object to the gui system .
. the type mgt needs to know
what operations can cause modifications
or it needs to compare before&after values
if any of it's outputable's are gui typed .
. not sure I was thinking of all that when I
designed the following ...]

. seems like the simplest gui system is to have
a gui ptr for each window you intend to export,
then the gui system knows to follow this pointer
and print whatever happens to be there .
. that way you don't have to decide at design time
what will be displayed .

[. to provide this feature of dynamism
combined with a gui system notfication service,
you simply mov from (x.gui.t) to (x.t; p.gui`= x)
and the system understands gui.types like p to be
dynamically type-tagged . ]

. if repointing the gui ptr dynamically,
and if we are translating adda to c,
then how is switching the gui ptr translated
into dynamically created gui views?
. our c datastructures must include type-tags;
if the type doesn't come with a type tag,
then the compiler has to do the boxing
(this is possible because
all symbols refering to untagged obj's
must be statically typed ).

. this complicates efficiency because
if the gui ptr can be dynamically changed,
then anything it might be repointed to
will have to be fully boxed (have type-tags included).
[. and obj's that are statically typed,
cannot be type-tagged;
so how are we getting notifications to happen?
. the compiler needs to know what will be gui'd;
if we want to do that dynamically,
then we'll need to compile dynamically
(eg, that means compiling to addm or python
instead of to a native lang like c or obj'c ).
. once the compiler knows what's getting gui'd,
then it knows when gui'd obj's are being assigned to
statically typed out.mode parameters
and it can notify gui mgt
after that parameter's procedure is done operating .]

6.30: needs a type-tag:
. gui-notify (is-mirrored) is like read-only subtype;
if modified {is-rom: raise error, is-mirrored: notify gui}
maybe there needs to be some additional implicit params
that provide bits for every subtype:
esp'ly is-rom, and is-mirrored?
. obj's don't need a read-only bit because
that is part of static typing,
but is-mirrored is a dynamic subtype
since we want the run-time to control what's mirrored and when;
thus any obj's that can be mirrored
will needs polymorph typetag indicating whether
gui needs to be notified when obj may have been modified .

6.30: keeping the mvc pattern in mind:

. the mvc pattern means that
programs don't use a gui directly,
they are designed to be used by other programs,
and if a human user needs access to a program
then we pair it with a gui-producing agent .
. keeping the mvc pattern in mind,
the parts we've referred to as being "(gui'd)
are generally known as the exported obj's
or the content of ipc* channels
*: (ipc: interprocess communications).

. just as human users have a window into an export,
other controllers have a buffer,
like what is offered by a file server
(rather than loading the whole file in memory,
it places the first unread chunk into a buffer)
what buffers have in common with user windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).

7.1: how is an obj's mirrors identified?:

. if we allow the mem system to be virtualized,
then when c provides the address of an obj,
we can no longer use that as an obj id,
because pages (and their obj's) are sharing physical addresses;
therefore, we need some way to identify obj's
in order for the notification system to work
(once some type mgt finds modifications require notification
the notification system needs to know
which obj in which channel needs to be updated;
so, it either has to map an obj id to these things,
or it needs to include with each mirrored obj
a notification id).
. if the notification bit were an entire word
then not only is this easy to read,
but also non-zero values can serve as notification id's .
. however, the whole point of it being a bit
is that this is something that has to happen to every obj type
(is this a mirrored subtype or not?)
so it should to be very space-efficient .
. if it's found to need notification,
then how is the system managing obj identity ?
is it the c-detectable address of the obj? .

Objective-C Categories

1.20: adda/type/obj'c categories:
. Apple is using the obj'c Category for mvc separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package
without any methods for drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one class can exist yet with
relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns
todo:
. isn't that use of categories needed only because
it's assuming something demanded by the current oop model?

. if your string wants to talk about gui-specific tricks
like font, or curve following,
that should be served by a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 diff'ing classes !)
--
that was a main point of the book"design patterns:
it was a critique of oop's use of subclassing;
and, that criticism can apply equally well to categorizing;
but, notice it does have a good purpose:
it allows separate compilation of extensions
without having to recompile the original interface
which would then require a recompile of
all the clients of that interface .

. but in this case, the category pattern is not needed,
the pattern to follow is this:
. the whole point of the mvc pattern is that
nearly all programming should be doable without having to
be aware of what your output device is .
. the same program I write for the command-line
should be apply without modification
to use by the gui-interfaced user .
. the runtime is supposed to have a default way of
visualizing your data structures graphically .
. the user is just another inout process
interacting with your process;
so, the gui should be handled by 2 generic packages:
it communicates with a concurrent process,
and then is also aware of 2-d or 3-d
placement preferences of datastruct's .

. so, how does adda let you define special effects
such as those specific to one style of gui?
eg, the curve-following text
needs a record (string, linedata),
and that record should have a particular name, say SL,
so then any var assigned the type SL
will be treated by the adda system as curve-following text
at least when dealing with the contexts
that are specified as customized by SL .
. the 2 primary contexts that work like that
are the user interface,
and the memory usage:
(persistent file, ram buffer, L1,2,3 cache).
. conversely,
when assigning an SL value to a native type,
then all gui-specific info would be dropped .

analysis of what it offers:
. the category has 2 use cases, depending on
whether you have the interface code,
or just have an interface document
that doesn't list the private ivars of the type .
. if you don't have the interface,
the diff' it makes seems purely syntactic:*
native functions can be stated oopishly: x`f();
and with categories you can start writing x`MYf() .
. that is offering more than just
adding a package whose input types are x`type:
the new package is being registered with the type,
so when I ask that type to apply a symbol named MYf,
the run-time engine is able to say it does .
. so, what is the equivalent to that
in lispy procedural (vs oop) programming?
. say the apply-operator is @,
I can then say ('f @ 'x) to mean f(x),
so that to apply dynamically any variable, X,
to any function, F,
I can write X`= 'x, F`= 'f, .... F @ X .
. it then looks to see if there exists a function f
that accepts x`type .
*: [1.31:
. even without affecting ivars,
the diff' it makes can be quite significant;
because, it can override methods that have
special systemic effects on the ivars,
and those effects will be missing .

. the oop syntax allows this:
x`f()`g()`h()
which means that x`f() returns an object x2
which, in turn, understands
what to do with g(), etc .
. so, the functional equivalent to x`f(...)`g(...)`h(...)
is h(g(f(x, ...), ... ), ...).
. that could mean the run-time is doing another check:
is there an f(x`type).y,
such that there is a function named g
that can accept y`type ?
. obj'c is not concerned with that though,
because once you assign a function to a particular type,
the run-time can quickly know to use
the function name f that is registered with that type .
. after that, it doesn't matter whether g can handle it;
because the object returned by x`type according to x`f
is offering no other choices .
. the reason obj'c does it this way
is for the other use case:
where the interface is known so then the
functions being added to x`type
need to register with x`type because
otherwise they won't be granted access to x`type's
private instance var's .
. this, then, is what obj'c categories uniquely do;
it's something like ada's child package feature .

std input and gui interaction drivers

12.27: adda/arch/std`input:
. in my idealized expression of the mvc pattern,
the designers of apps should never have to
program the details of the user's gui;
they simply write to data structures,
and the user`agents have their favorite ways of
expressing structures graphically;
but what if the app designer
wants to contribute new ways of
graphical interaction ?
. such gui drivers shouldn't get direct access
to the mouse and keyboard (input events);
instead, like unix is designed,
drivers get gui events from std`input;
and, the user`agent is free to
feed the gui driver either the actual input events
or the user`agent's version of input events .
[12.29: for modularity:
. the gui driver's usefulness to some users
may depend on the user`agent's ability to
filter the user's input,
or simulating it with an algorithm;
eg, an adaptation for those with the shakes
might be to filter duplicate inputs .
adde plug-in's:
. the general way to develope the gui
is for adda, the compiler,
to be aware of plug-in's for adde, the editor;
a gui driver is associated with a typemark,
and then when adde is displaying
items of that type,
it lets the associated gui driver
decide how inputs translate into
modifying a value of that type .
. there can also be event-triggered gui drivers
(vs triggered by accessing a certain type)
eg, a selection lasso driver
would be triggered by a mouse-down drag,
and instead of stopping at mouse-up,
it would keep accumulating selection rectangles,
until, say, the enter key was pressed .]

universal mvc`controller for mac

10.7: adda/automator built-in:
. noticing that mac.automator's library
had no 3rd-party app's,
I realized that app scriptability
was like the gui automation:
it should be baked right in .
. most app's can be engineered to be
bot-friendly first, and then wrapped in a gui
that is human-friendly;
the app maker doesn't have to deal with
graphics at all, just basic data structures
that the system is known to have graphics for .
. this is the way to pervasive app scriptability;
I'm wondering what it is about mac app's
that prevents the system
from seeing and using operations bots can reuse .
. it might have to do with
app developers' privacy and control issues .

exception mgt

11.9: adda/exception mgt/intro:
. we expect some errors;
because, we'd like to
use some software before having to
formally verify its correctness,
so, we compensate
by finding ways to limit damage:

# isolation:
. modules should never crash other modules:
we can verify a microvisor or microkernel,
and it enforces the firewalls between processes .
. addx should be such a microkernel design;
[11.12: just as the app doesn't have
direct access to the user (it's the mvc`model
while adde is the view&controller )
it also has no direct access to the machine:
all c-level activity is handled by addx|addm .]

# regularly yielding to the gui coroutine:
. a critical priority of addx
is never letting the gui be unresponsive;
this is done by having adda embedding calls to addx
at every place in a subrogram that could
mean more than a milisec of cpu time:
# inside every function call,
# inside every loop .
. this is cooperative multi-tasking with
system-enforced coroutine yielding
for paravirtualizing true multi-tasking .

# regular reporting to supervisor:
. getting a regular progress report
will limit waiting on the down employee .
. employees can be waiting on
down service providers;
loops can be waiting on a terminal condition
that never arrives;
as when there's unexpected input;
mutual recursions (eg, f->g->h->f)
are another form of looping;
deadlocks can cause indefinite waiting,
but those can be avoided by
proper use of concurrency,
and by not locking resources
(using queues instead).
. a subprogram can be waiting because of
a failure to establish dialog with the user
(eg, if the system allows a window to be
always on top,
then dialog windows may be hidden from view).
. all threads are periodically tested for
whether they're waiting for a job offer,
for a {service, resource},
or are performing a service;
in which case,
addx measures how long ago the thread
produced its latest progress report .
. the progress reports read like a narrative
that a human would appreciate;
to make these reports quick,
msg's are encoded, so that each msg
is represented by some value in a byte (0...255)
(or a 16-bit integer if this subprogram had
more than 256 msg's).

# blackbox recorder:
. it tells us what was going on
just before a crash .
. it saves the progress reports,
and the recent call chain .

# a debug mode:
. when users' tools are not working well,
some users may like to see what's wrong
by using developers' visualization tools;
eg,
a freezing problem can be illustrated
as a looping call chain:
. the tool collects all the recent calls
(saved by the blackbox recorder)
then tries to find a recursion,
and shows the list of calls that are repeated .

11.8: sci.adda/exception mgt/reporting#loop count approximations:
[11.11: obs:
. it would be better to use progress reporting .]
. if adda can't statically figure out
when a loop won't terminate,
it should remind coders to give
approximate loop counts;
then the run-time can use that how?
sci:
. before the loop entry,
adda sets the counter, and a limit,
then has the scheduler check the limit .
. scheduler doesn't have to check all the time;
but if 2sec's go by,
nearly all loops are done by then,
if there is no limit given,
it starts giving it more cpu time if it can,
so the real time is compressed,
if another sec goes by
and there's other jobs to do,
then it starts getting starved ?
it could be doing a huge job!

mvc and observer notifications

6.21: addx/mvc and observer notifications:

. if there is a std graphics api like opengl,
shouldn't scripted app's have access to it ?
[6.27: how to keep mvc separation?
the model is using graphics to
make data components;
then the view can still have control in display
(graphics can be thumb-nailed,
displayed in a box of the intended size
but with descriptive text inside, etc ) .]

. the core system needs to build from
mac's idea of encouraging
all app's to provide an interface
that other app's and scripts can use
for using the services of that app .
[6.27:
. if the model does have some
new way of letting the user generate
data that is based on graphics,
then in a strict mvc model,
the model programmer will need to
contribute to the controller's code
through a plug-in architecture .
eg, the basic adde will have only
the sort of gui dynamics needed for
generating text and pictures .
. these behaviors will be bound to
the relevant datatypes;
a model can extend adde to do games
by binding a plug-in to game types
that explains how to display interaction .
. the proof of mvc separation will be
that adde, or the user's chosen controller
can show robots or networked users
playing the same game .
(game architecture should be based on
layers of activity
so as to minimize redrawing
and instead rely on compositing;
when something affects a model
all it's observers (view controlers and robots)
need to be notified .) ]

mvc with client-server architecture

6.20: addx/mvc with client-server architecture:

. strict mvc means model lets
controller do the image writing to screen .
. if part of the model includes
generating images,
then these can be composited
by the controller
to wherever the chosen view is .

. the x server allows remote servers
to be treated similar to local servers .
. the addx server model is not
concerned with such networking;
the main point is mvc modularity:
. the servers providing an mvc`model
need to be working for mvc`controllers
not for the human users directly .
. the model can then be used either by
human views or robotic views;
most typically, the point is to provide
more choice for the human
by letting a robot filter what the
model is intending for the human,
similar to the way bodyguards work .
[6.26:
. this isn't meant to escape from
contracts like google's
where the ad's must be human-visible
and the inquiries human-initiated;
it simply means that all models
are capable of robot accessability .
. one way this can help while
fulfilling the google contract
is to have the robot help with
making wise keyword choices:
it presents a list of suggestions
and the human can merely press enter .
. robots can also be reading along
to help humans spot the best leads .
]
. in addition to that mvc architecture,
the model may want to divide itself
into server and client parts
in order to efficiently modify the model
from afar .
[my intuitive assumption:]
. the x window system works on the idea that
it would be most efficient if
the os could provide a generic client part
that many servers could use,
since servers often need to make similar moves .

api:
. don't I need to have a
carefully selected set of api's
in order to know how to do the
x thing (where the model has
separate server and client parts) ?
. one could take it
one example at a time:
cloud computing depends heavily on x:
. some things like controlling the cursor
can't be done quickly eno' by remote .
. if the model does some
major modifications
the data needs to be with the server;
that's where it originates from,
so no problem .
. letting the user quickly scan
large portions of data
means that the data should be
mirrored there too
unless the platform is tiny .

review of higher view:
. mvc works naturally with x,
since the Server = Model
and the Controller along with its
choice of View = Client .
. the View consists of
the Controllers way of arranging
the data in a form that is
optimal for viewing .
. remote does complicate things a bit:
the non-remote controller has
instant access to the model,
but now with the model so far away,
the controller is having to think about
how much to ask for in advance
depending on the size of the local system .


6.26: addx/x protocol/server client terminology:

The term server and client have different meanings.
XServer runs on your graphically rich desktop
(it serves up the view)
X11-client (like app is client of OS)
may run anywhere on the connected network

lwn.net:

The program which provides access to
system resources (display, keyboard, mouse)
is the server.
The shorter-lived applications
which connect to the server
to make use of these shared resources
are the clients.
This is perfectly consistent with
every other use of "(client/server) .
What throws people is that
we're used to thinking of servers as
a particular type of *hardware*,
steadily ticking away the CPU-hours
in some climate-controlled back room,
out of sight, whereas "clients"
are the visible workstation PCs
at everyone's desk.
However, the X client/server terminology
is perfectly reasonable
from a *software* point-of-view,
and X is software, not hardware.

user-mapped gesturing

3.23: adde/multitouch and gestures:
. most of those 2-finger gestures of multitouch
could also be done with one finger;
you just need a convention like up-swipe is zoom-in,
and down is out .
. with single-finger swipes
we could avoid most of those annoying little control boxes .
. there are cheap track pads for most platforms,
and they offer the same thing as a touch screen .
. gesture controls should also have the mvc architecture,
where the users can customize the mapping
from gestures to actions,
so they can do what makes sense to them .
. with the ability to see the strokes they draw,
then even if the app' they're on is hesitating to respond,
the gesture's visual overlay is always quick to
give them graphic feed back .

3.23: adde/themes that are user-controled and snappy too:
. one reason mac doesn't like to change its themes
is to keep things snappy,
implying all rendering needs to be in the kernel;
but you can customize and have snap too
by keeping the feedback lightweight .

vnc integration

11.23: adde/vnc integration:

. the mvc and journaling arch' can make it easy to

do a vnc system;

so, try to be more inclusive of that feature .

that should be considered a design goal .

user`agent/can it be trusted?

10.1: adde/user`agent/can it be trusted?:

. one reason an app may want to do its own gui

is when it doesn't trust the environs;

eg, it may be infected by keylogger .

. with that in mind,

one must be careful about the addx architecture

appearing to have the same vulnerability as the matrix .

. some secure.wares like keepass are openware,

so there it's possible to integrate .

. it's an empty concern however,

because if addx is not controlling the whole platform;

it's discipline is applied only to

programs under it's control;

the user can still access other programs directly .

. if addx could have complete control,

there would be no way to get key.logger infections .

mvc customization (model-view-controller pattern)

8.12: adde/high-cpu and custom interaction:

[12.20:

. a key feature for ease of programming and reuse

is that any program written as a library for software to access

will auto'ly have a gui generated for the user to access;

but how can that work when there is moment-by-moment,

2-way interaction between user and app' ?

]

. how is the task switching done fairly

when the content has to change in order to

continue the interaction?

. the adde model assumes all things are

expressed through std widgets?

how can an app' add widgets?

how can system trust the additions?

. the fundamental widget

is a set of hyperpoints layered on graphics;

[hyperpoints are my name for the familiar selection points

which are used for resizes, moves, or shape-changes .]

. you can move the hyperpoint at your speed,

and the image follows at maybe a slower speed,

so then the immediate graphic (the point)

is remaining very responsive

even if the full effects of the response are slightly delayed .