2012-07-25

Mac gets some optional Sandboxing

6.2: news.cyb/dev.mac/sandboxes
Apple brings sandboxing to the desktop:
. most PCs have not been into sandboxing
[because backward compatability was an issue;
smartphone platforms are more recent inventions,
so sandboxing is an obvious good .]
. to access resources within a sandbox,
apps must request “entitlements” [aka, capabilities.]
Android apps must ask the user for permissions
and then the OS constrains the app
to the allowed permissions .
[ but Android apps may be all-or-nothing:
either the user accepts all the requests,
or else the app fails to be usable at all .]
Apple’s iOS sandboxing doesn’t involve the user,
as all permissions are handled by
Apple's App Store evaluators .
[7.25:. in order to be accepted into the app store,
developers must divide their app into modules
so as to more easily explain why each part
needs a particular set of entitlements .][7.20:
Apple decides for the user,
what entitlements are appropriate,
not only for the whole app,
but more smartly, for each of its modules .]
. iOS users can still control certain entitlements:
(eg, opening a list of recent files
or saving documents elsewhere in the file system).

Concerns from Developers:

# no more AppleScript:
[7.20:
AppleScript is a programming language
meant to allow the user to reuse apps
by having scripts make calls to apps .
. if an app wants to reuse other apps,
then it too can use AppleScript
to make calls to other apps;
however, in sandboxing this can't be done,
because,
when an app is entitled to AppleScript
it's entitled to anything AppleScript can do
-- which is basically anything!
. if apps are instead designed to be
reused directly by other apps
then sandboxed apps can still be
entitled to use particular other apps
without having to give them access to
the wide world of AppleScript .]
# no more file system management: [7.20:
. Apple sandboxing asks the user
for each and every file access;
so, apps that need access to many files
or that need to work in the background
are not considered sandboxable;
nevertheless, sandboxing of the file system
could work like vmware's shared folders:
. vmware lets you run an OS in a sandbox
as a virtual machine (vm);
and then gives the vm {read, write} access
to just the folders the user requests
(Virtualbox has a similar feature).
. you can divide your file system by sensitivity levels;
eg, if the sandboxed app has access to the web,
then give it entitlements should be
read-only access to non-sensitives,
and write access to a downloads folder .
. letting sandboxes share folders
is important to generativity .]
. see Jonathan Zittrain's Chapter 7 of
The Future of the Internet and How to Stop It .

2012-07-19

Python with GUI on Mac

6.30: summary:
. after seeing David Mertz's
Text Processing in Python/SECTION 3
/Platform-Specific Operations,
I'm seeing Python has a Carbon API,
which you'll now see is deprecated,
so, I wondered if there's a Cocoa API now .

. other than extending and embedding C,
python is not really supporting cocoa:
. the latest python version does offer
platform-specific modules
but only for Windows and Unix
(unix does includes mac and any
Cocoa binaries that are runnable from the shell,
so our access core services
is by feeding text to a shell?! ).

. the best idea I found was ObjP:
-- much less complex than PyObjC --
it's a code generator that helps with both
embedding python into obj'c,
and extending python with C
from which you can use obj'c .
. if you'd still rather use PyObjC,
there is support for it in xcode 4 .
(see Xcode4CocoaPythonTemplates)

. a future idea I found from this search
was a python equivalent to Apple's MacRuby:
instead of being a bridge to cocoa,
it would have Python implemented in Cocoa
-- just like Jython is impl'd in Java . Mython ?

6.30: AppleScriptable or stay with Python?:
. mac's vision for scriptable app's
revolves around the use of AppleScriptObjC,
which expects you to write your tools in obj'c,
and then compose tools using AppleScript .
. obj'c can compile and run AppleScripts
by using NSAppleScript .
. Python can do the same with osascript
-- call AppleScripts from python --
or
NSAppleScript -- build & run it in Python .
. see Designing for Scriptability
about ensuring your interface language
fits in with AppleScript ...
and before you give up, consider this:
many of your users
might rather reuse your code with
Apple's Automater or Applescript Editor
than with python's tools .

2012-07-17

android vs iOS

6.13: news.cyb/dev.android/compared to iphone:
7.17: summary:
. suprised to learn that Android dev's
tend to rely on ad' trackers for revenue;
whereas, iphone dev's expect users to pay .
. both platforms have problems with
backward compatibility of apps,
but Android also has problems with
make- and model-specific apps .

Pragmatic Starter Kit Books

6.21: news.cyb/dev/Pragmatic Starter Kit Books:

     Pragmatic Version Control
     Pragmatic Unit Testing
     Pragmatic Project Automation

6.25: what is Project Automation about?:

2012-07-05

juggling user expectations

6.18: adde/mail/bcc info during a forward:
. how to build a mail system that
impl's blind carbon copy with no leaks?
. say you have that bcc'd email sent
and then you start to forward your view of it;
it shows both who it was sent to
and who it was cc'd to, but not the bcc's?
. wouldn't we want to give you the option?
(ie, you'd have to edit bcc if abstain)
but what if the naive user is not expecting it
even while the power user is demanding it ?
. do you notify the user that bcc is apparent in forward ?
require dialog before creating the forwarding process ?

supercomputing programming languages

6.20: web.adda/supercomputing programming languages:
personal supercomputing:
The personal supercomputing idea
has also gained momentum thanks to the emergence of
programming languages for GPGPU
(general-purpose computing on GPU's).
. Nvidia has been trying to educate programmers
and build support for CUDA,
the C language programming environment
created specifically for programming GPUs.
Meanwhile, AMD has declared its support for
OpenCL (open computing language) in 2009 .
[6.25: web: the c in OpenCL stands for
computing not concurrency?

OpenCL (Open Computing Language) is the first
open, royalty-free standard for
general-purpose parallel programming of
heterogeneous systems.
OpenCL provides a uniform programming environment
for software developers to write efficient, portable code
for high-performance compute servers,
desktop computer systems and handheld devices
using a diverse mix of multi-core CPUs, GPUs,
Cell-type architectures
and other parallel processors such as DSPs.]
OpenCL is an industry standard programming language.
Nvidia says it also works with developers
to support OpenCL.
roll-your-own personal supercomputers:
. researchers at the University of Illinois were looking to
bypass the long waits for computer time at the
National Center for Supercomputing Applications;
so, they built “personal supercomputers,”
compact machines with a stack of graphics processors
that together can be used to run complex simulations.
. they have a quad-core Linux PC with 8GB of memory
and 3 GPUs (one NVIDIA Quadro FX 5800,
two NVIDIA Tesla C1060) each with 4GB .
any news on darpa's HPCS program
(High Productivity Computing Systems)?

2012-07-04

willowgarage's personal robotics platform

6.18: news.adds/openware/
willowgarage's personal robotics platform:
open source robotics platform
. Willow Garage's mission is to
help advance the state-of-the-art in
autonomous robotics technologies.
. great advances in robotics will come from
the open source community.
Willow Garage is working on all levels of software
from the ground-level ROS (Robot Operating System)
to their collection of ROS-enabled software packages.
. they're also helping application engineers
understand camera, video, and 3D point cloud data
with the OpenCV
and Point Cloud Library (PCL) perception libraries.

scriptability with sandboxing

6.30: addx/scriptability with sandboxing:

. I was surprised to learn that Preview
-- one of Apple's own apps -- is unscriptable;
but, perhaps that's because it's so costly to produce
the needed scripting dictionary .
. one of addx's motivating features
was the pervasive use of the MVC pattern;
with that in place, app's always come in 2 parts:
# the model that can talk to any controller
(because it's a command line tool);
# the gui controller that humans will need
in order to interact with the model .
. the scripting dictionary comes free
(without the developer having to do anything)
because in order to get an app installed in the system
it had to be submitted to the system librarian,
who put the model's specification in the library
which is viewable by humans and controllers alike .

can a scripting engine really be safe?

6.1: addx/can a scripting engine really be safe?:

. I just heard that Apple will no longer allow apps to
communicate by sending each other AppleScripts;
instead they need to use each other's API .
. this I found confusing because I had a different understanding
of applescript connectivity:
. apps exported an API that applescript could understand,
and then applescripts could use all such apps .
. I guess what they were saying is that, counterintuitively,
only AppleScript had been able to use such API's:
you couldn't do so from the native lang (objective C).
. anyway, this got me to asking the question:
can a scripting engine really be safe?
here's my yes:

2012-07-03

value or symbol literals

6.21:  adda/lexicon/$symbol can indicate
literal symbol just like quotes mean literal string:
[7.2:
. there are 3 categories of symbols:
# names composed of digits are literal values of type number;
# names preceded by double-quote are literal values of type character string;
# names preceded by single-quote are unevaled symbols
(references to a symbol that was previously declared);
# names preceded by ($)  are declaring literal values of type symbol;
(it's not a variable or constant representing some other value).
. in english we would tend to put a word in quotes to mean this,
but in a programming language, we want to reserve quotes for
values of type character string .
. this use for $ was first mentioned as
a namespace for value literals .]

tuple literals

6.21: adda/syntax/use of colons to delimit tuple components:
. I wonder if could use python's colon syntax for numeric typing
and still be able to use colons in the usual way
if I am omitting the space: eg, label: t:u:p:l:e .
. this use of omitted space has its precedent in (-),
where minus looks like this: x -y,
while x-y is single name .
if omitting to express default
my way needs something like *:*
because in python the full syntax is [:]
but I have other plans for [],
seq#*:* = python's seq[:]
[:] is a symbol spelled with a colon .

6.29: adda/subparameter delimiters:
. the python string parameters ( start, stop, step )
are delimited by (:) .
. they are like sub parameters,
where instead of a, (1,2,3), c
you can use subparameters to avoid overusing parentheticals:
a, 1:2:3, c .
. the python syntax comes from prior use of (:) to express ranges
-- I first saw this syntax in spreadsheet formulae .

2012-07-02

automated range tracking

6.20: adda/type"float/automated range tracking:
. the float type should be replaced with the real range;
ie, as users of scientific calculators,
we're supposed to be doing this in our heads,
but a friendly calculator needs to automate this .
. for literals there could be an implied range
given by +|- 1 of the most significant missing digit,
eg, 1 = 0.9..1.1 because
it's missing 0.x so it's 1 +|- 0.1 .
. after literals the range cannot be implied;
we must keep track of how much operations are widening it .

asynchronous communication and promises

6.15: adda/co/asynchronous communication and promises:

. the idea of protected types vs task types
 is about whether the interaction is using an entry queue .
[6.17:
. this reminded me of what promises are:
task types are taking orders on paper,
ie, instead of being called directly,
the callers put their call details in a queue
just like a consumer-waiter-cook system .
. the ada task is designed to make the consumer wait
(ie, do nothing until their order is done);
but this doesn't have to be the case;
because, instead of blocking the caller's entire process
we could put a block on some of its variables instead;
eg, say y`= f(x) is a task call,
so the caller must wait because
the rest of its program depends on y's value;
and, y's value depends on that task call, f, finishing .
. however, we could block access to y,
such that the caller can do other things
up until trying to access y .
]
. notice in ada's style
both protected and tasking types are blocking;
ie, synchronously communicating .
. how do we ask instead for
asynchronous communication ?

we don't need new syntax because
functions logically require blocking
whereas message-sends do not .
. by logically I mean
the function code is saying:
"( I am waiting for this return value), ...
[6.17: not true:
. asynchronous behaviour should be encoded in syntax
because it does make a difference at a high level:
. the only reason to feature asynchronous calling
is when the job or its shipping could take a long time;
if the job is quick
then there's no use bothering with multitasking,
and conversely, if the job is slow,
then multitasking is practically mandatory;
and, multitasking can be changing the caller's algorithm .
]
. there are 2 ways to ask for asynch:
#  pass the address of a promise-kept flag
that the caller can check to unblock a promised var;
# caller passes an email address
for sending a promise-kept notification:
the caller selects an event code
to represent a call being finished,
and that event code gets emailed to caller
when job is done .

. the usual protocol is to
have the called task email back to the caller
a pointer to the var that has been updated,
so if there are multiple targets,
the async'ly called might send an email for each completion,
or they could agree that when all is done
to email the name of the async sub that has finished;
but if caller wants to know which job was done;
then only the event code idea would be indicating
a per-call completion event .

6.26:  news.adda/co/perfbook:
Is Parallel Programming Hard, And, If So, What Can You Do About It?
Paul E. McKenney, December 16, 2011
Linux Technology Center, IBM Beaverton
paulmck@linux.vnet.ibm.com
2011 version:
src:
--
seen from here: cpu-and-gpu-trends-over-time
from: JeanBaptiste Poullet @jpoullet
Bioinformatician/statistician
, next generation sequencing (NGS),
NMR, Linux, Python, Perl, C/C++



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 .]

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? .