Re: [stack] A Joy VM in OCaml

>> OTOH perhaps such "democratic committee" projects aren't feasible.

> I believe good results require a sufficiently annoying `itch' locally
> applied to a single implementor / designer.

Yes, you're talking about making fish.
I'm talking about making fishermen.

Most of the value-added in computing comes from the soft: psychology
  and human-cognition.  OTOH the Hard: technology; is easier to talk about.

Eg. the only justification for music is 'emotion manipulation'.
But that's near impossible to quantify or describe.
OTOH volumes are/can-be written about the technicalities.

My previous laboured example, perhaps didn't prove the conclusion:--

The brief sequence of functions described by:
 " pstree -p | cut -b25- | grep su ".
which does:
 print the process-tree,
 but cut-out and show only the part of the lines, from the 25th char
to end-line,
  and show only lines which contain the string "su";

shows a very cognitive economical way of achieving the goal.

And has the very important advantage of being achieved by successive refinement.
Which makes for increased productivity.

But I'm still waiting for for an explanation if/why joy is good.
And I expect the outcome of any effort to pay-back in the future.
Education, knowledge of universally applicable principles is more profitable
than aquiring *A* product.

== Chris Glur.




On 9/3/09, eas lab <[email protected]> wrote:
> .. continued fron previous post, because the mailer objected to the
> complete text.
> ------------
> Because I'm an isolated researcher, I appreciate when others expose
> the route to their results, rather than just giving the 'show-room'
> end product.  Perhaps some see this as indiscreet exhibitionism ?
>
> As an example of how I'd like open-collaborative projects to be,
> I'm going to NOW try to expose how I partially achieved a nasty task
> using unix's cat-like facilities.
>
> TASK DESCRIPTION: find which [if any] Desktop, VT pair is currently 'open'
> at
> the correct directory, to process the newly arrived email, news, http
> ...etc.
>
> Think of a system from 200 years ago, where 10 to 20 sheets for 6 to 8
> categories are distributed between 4 clerks. Clerk1 may have 4 sheets for:
> vegetables, meat, clothing, meat.
> When a transaction for meat arrives, it should be directed to the clerk
> who currently has the/a 'meat' sheet.
>
> Since this is a computer and not paper-sheets, multiple clerks/processes
> can have the same sheet/directory open.  And muliple copies of a
> sheet/directory
> may be open for reading/editing its files. And always allocating new
> sheets/VirtualTerminals to the new topic as they arrive would give an
> explosive
> growth of redundant sheets/VTs.
>
> If you had 20 copies of a book, all open, mostly at different pages
> and you had to switch between books to see which, if any book was open at
> the 'meat page', this would be frustrating; compared to scanning down a list
> of (book, page-topic) pairs, to find the/a 'meat' book/page.
>
> So the 1st REFINED TASK DESCRIPTION is:
> find which Desktop/VT, if any, has the directory for the newly arrived item.
>
> Then the 2nd REFINED TASK DESCRIPTION 'became':
> generate a list of the open directories for the 10 to 20 mc-tasks,
> and generate info which relates the (D,V) pair to the  task-directory,
> so that by visually scanning the 2 lists the D/V which matches the mc-task
> can be found.
>
> As an example this task that I'm writing now, will be in a path/directory
> *cat* or *Cat*; and I can see that it's using desktop1, VT4; which I
> designate as D,V=1,4.
>
> But when I switch out of this D,V to some other jobs and new info arrives
> for
> the 'cat' topic, I'll have forgotten/lost D,V=1,4.  In fact possibly D,V=1,4
> will have been allocated to a different topic.
>
> The 2 sets of info look like this [where I just have to remember that
> they're
> call PT & DV] :-
> --> # PT
> mc         1477   /mnt/cdrom/Inet
> mc         1549   /mnt/cdrom
> mc         1593   /mnt/cdrom/Legal/TLC/Aug09
> mc         1824   /mnt/cdrom/Legal/TLC/Aug09
> mc         2429   /mnt/cdrom/Inet/RSS
> mc         8952   /mnt/cdrom/Legal/TLC/UKdefaultJ
> mc         9837   /mnt/cdrom/Legal/TLC
> mc        13406   /mnt/cdrom/Legal/TLC/UKdefaultJ
> mc        13529   /mnt/cdrom/Legal
> mc        13570   /mnt/cdrom/Legal/TLC/PreApr09
> mc        13925   /mnt/cdrom/AI/Catamorfic
> mc        17614   /mnt/cdrom/Legal/TLC/PreApr09/CCnewJudges
> mc        24024   /mnt/cdrom/Legal/AudtrFiduc
>
> --> # DV
> |-kdeinit(1186)-+-su(1196)---bash(1271)---mc(13529)---bash(13531)
> |               |-su(1199)---bash(1303)---linux.oberon.no(14102)
> |               |-su(1201)---bash(9009)---mc(13570)---bash(13572)
> |               `-su(1203)---bash(9805)---mc(9837)---bash(9839)
> |-kdeinit(1188)-+-su(1204)---bash(1335)---mc(1593)---bash(1595)---less.bin(19649)
> |               |-su(1207)---bash(1367)---mc(1824)---bash(1826)
> |               |-su(1209)---bash(1399)---linux.oberon.no(1431)
> |               `-su(1211)---bash(9481)---lynx(17276)
> |-kdeinit(1189)-+-su(1213)---bash(2075)---mc(17614)---bash(17616)
> |               |-su(1215)---bash(2107)---mc(2429)---bash(2431)
> |               |-su(1218)---bash(2139)---mc(13406)---bash(13408)
> |               |-su(1222)---bash(2171)---sob(9671)---oberon(9712)
> |               `-su(1225)---bash(8919)---mc(8952)---bash(8954)
> |-kdeinit(1192)-+-su(1221)---bash(1235)---linux.oberon.no(1441)
> |               |-su(1226)---bash(1445)---mc(1477)---bash(1479)
> |               |-su(1265)---bash(1517)---mc(1549)---bash(1551)
> |               `-su(13889)---bash(13893)---mc(13925)---bash(13927)
>
>
> This can look a bit overwhelming, but searching for the 'cat', we find
>  /mnt/cdrom/AI/Catamorfic
> as the 3rd last element, and with a pid-number of: 13925.
> And the 2nd info-set has mc(13925) in the 4th/last branch of the node
> which has linux.oberon.no(1441) as it's 1st branch.
>
> Which means DV=1,4 as we already know !
> Similarly we see that the 2 'tree-branches' which are already allocated
> to "Aug09", are D,V=3,1 & D,V=3,2 , via pid=1593 and pid=1824 .
>
>
> Up till now, I've had to use the hack of puting the 'oberon' in the
> N-th VT of the Nth Desktop, in order to see which Desktop a set of
> branches represent. Obviously I'd like some kind of 'artificial
> intelligence' method to further proccess and just place the D/V pair
> next to the corresponding directory-path.  Like so:-
> 1,2= /mnt/cdrom/Inet
> 1,3= /mnt/cdrom
> 1,4= /mnt/cdrom/AI/Catamorfic
>  ...etc.
>
> But ! by using successive refinement, one can get the benefit of the
> partially working product and finish it later --  or never.
>
> Finally ! let's see [by exposing the details of my thought process]
> how this came from cat-style linux facilities.
>
> 1. Let's examine the minimalist cat-code to see what it does.
> 2. where is the code, to be found to examine?
> 3. since it's executable, linux's "whereis" will show us.
> 4. do: "whereis PT"   gives us: "PT: /usr/local/bin/PT"
> 5. and show the contents of the script/executable-code
>   ie. "cat /usr/local/bin/PT"  shows the single line:-
>  "lsof | grep DIR | grep mc | grep "/".  | cut -b-17,67-"
>
> BTW, this is an example for windows-users of what linux does;
>  and truthfully the file/script had several lines of comments
> which accumulated during its evolution which I'm excluding.
>
> If I look at the line of: code, I guess this is what it does:
>  lsof : list all the open file,
>  | grep DIR : but show only the lines containing "DIR"
>  | grep mc : and of those show only the lines containing "mc"
>  | grep "/". : and of those show only the lines containing
>                  "/"<some non 'bad chars'>
>      {I NOW don't remember exactly which char=set "." represents}
>  | cut -b-17,67- : and show only parts of the line/s, probably cutting-out
>     pieces at boundries 17th char & 67th char.
>
> NB. the parts which I'm not NOW sure about should be explained in the
>  script's comments.  But I'm not 'sanatizing' and pretending that I know.
> -------------
> And similarly the cat-like-code for "DV" is:
>  pstree -p | cut -b25- | grep su
> which apparently does:
>  print the process-tree,
>  but cut-out and show only part of the lines, apparently from the 25th char
>    up to the end,
>  and show only lines which contain the string "su".
>
> Which I guess gives the 2nd data structures above.
> BTW for 'win users':
> if you've previously typed : "cat /usr/local/bin/PT"
>   it only needs 3 keystrokes to get: "cat /usr/local/bin/DV"
> although I prefer ETH-oberon which works without any keyboard, if need be.
>
> Hopefully this example shows how comfortable it can be to develop a large
> class of tasks in a cat-style language.
>
> It would be valuable for me, and possibly for others, if cat-contributors
> could refine the above down to a lower level. Ie. the implementation of
> "grep:
> and eg. "tr" in a cat-like language would be valuable.  Frankly I don't even
> know how joy implements its control-structures, because I never found a
> "TOP"
> view of what joy was good for.
>
> The basis of the "hello world" approach is that a demonstrable model is
> made available as soon as possible; and then later one can see how the
> actual
> characters are printed - at a lower level ?
> The top-goal must be exposed before the implementation details.
>
> == Chris Glur.
>