subject:"Re\: \[fonc\] Error trying to compile COLA"


On 3/1/2012 3:56 PM, Loup Vaillant wrote:

Le 01/03/2012 22:58, Casey Ransberger a écrit :

Below.

On Feb 29, 2012, at 5:43 AM, Loup Vaillant  wrote:


Yes, I'm aware of that limitation.  I have the feeling however that
IDEs and debuggers are overrated.


When I'm Squeaking, sometimes I find myself modeling classes with the 
browser but leaving method bodies to 'self break' and then write all 
of the actual code in the debugger. Doesn't work so well for hacking 
on the GUI, but, well.


Okay I take it back. Your use case sounds positively awesome.


I'm curious about 'debuggers are overrated' and 'you shouldn't need 
one.' Seems odd. Most people I've encountered who don't use the 
debugger haven't learned one yet.



Spot on.  The only debugger I have used up until now was a semi-broken
version of gdb (it tended to miss stack frames).



yeah...

sadly, apparently the Visual Studio debugger will miss stack frames, 
since it apparently often doesn't know how to back-trace through code in 
areas it doesn't have debugging information for, even though presumably 
pretty much everything is using the EBP-chain convention for 32-bit code 
(one gets the address, followed by question-marks, and the little 
message "stack frames beyond this point may be invalid").



a lot of time this happens in my case in stack frames where the crash 
has occurred in code which has a call-path going through the BGBScript 
VM (and the debugger apparently isn't really sure how to back-trace 
through the generated code).


note: although I don't currently have a full/proper JIT, some amount of 
the execution path often does end up being through generated code (often 
through piece-wise generate code fragments).


ironically, in AMD Code Analyst, this apparently shows up as "unknown 
module", and often accounts for more of the total running time than does 
the interpreter proper (although typically still only 5-10%, as the bulk 
of the running time tends to be in my renderer and also in "nvogl32.dll" 
and "kernel.exe" and similar...).



or such...

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Loup Vaillant


Le 01/03/2012 22:58, Casey Ransberger a écrit :

Below.

On Feb 29, 2012, at 5:43 AM, Loup Vaillant  wrote:


Yes, I'm aware of that limitation.  I have the feeling however that
IDEs and debuggers are overrated.


When I'm Squeaking, sometimes I find myself modeling classes with the browser 
but leaving method bodies to 'self break' and then write all of the actual code 
in the debugger. Doesn't work so well for hacking on the GUI, but, well.


Okay I take it back. Your use case sounds positively awesome.



I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems 
odd. Most people I've encountered who don't use the debugger haven't learned 
one yet.



Spot on.  The only debugger I have used up until now was a semi-broken
version of gdb (it tended to miss stack frames).

Loup.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 3/1/2012 2:58 PM, Casey Ransberger wrote:

Below.

On Feb 29, 2012, at 5:43 AM, Loup Vaillant  wrote:


Yes, I'm aware of that limitation.  I have the feeling however that
IDEs and debuggers are overrated.

When I'm Squeaking, sometimes I find myself modeling classes with the browser 
but leaving method bodies to 'self break' and then write all of the actual code 
in the debugger. Doesn't work so well for hacking on the GUI, but, well.

I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems 
odd. Most people I've encountered who don't use the debugger haven't learned 
one yet.


agreed.

the main reason I can think of why one wouldn't use a debugger is 
because none are available.
however, otherwise, debuggers are a fairly useful piece of software 
(generally used in combination with debug-logs and unit-tests and similar).


sadly, I don't yet have a good debugger in place for my scripting 
language, as mostly I am currently using the Visual-Studio debugger 
(which, granted, can't really see into script code). granted, this is 
less of an immediate issue as most of the project is plain C.




At one company (I'd love to tell you which but I signed a non-disparagement agreement) 
when I asked why the standard dev build of the product didn't include the debugger 
module, I was told "you don't need it." When I went to install it, I was told 
not to.

I don't work there any more...


makes sense.


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Casey Ransberger

Below. 

On Feb 29, 2012, at 5:43 AM, Loup Vaillant  wrote:

> Yes, I'm aware of that limitation.  I have the feeling however that
> IDEs and debuggers are overrated.

When I'm Squeaking, sometimes I find myself modeling classes with the browser 
but leaving method bodies to 'self break' and then write all of the actual code 
in the debugger. Doesn't work so well for hacking on the GUI, but, well. 

I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems 
odd. Most people I've encountered who don't use the debugger haven't learned 
one yet. 

At one company (I'd love to tell you which but I signed a non-disparagement 
agreement) when I asked why the standard dev build of the product didn't 
include the debugger module, I was told "you don't need it." When I went to 
install it, I was told not to. 

I don't work there any more...
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 3/1/2012 10:12 AM, Loup Vaillant wrote:

BGB wrote:

there is also, at this point, a reasonable lack of "industrial strength
scripting languages".
there are a few major "industrial strength" languages (C, C++, Java, C#,
etc...), and a number of scripting languages (Python, Lua, JavaScript,
...), but not generally anything to "bridge the gap" (combining the
relative dynamic aspects and easy of use of a scripting language, with
the power to "get stuff done" as in a more traditional language).


What could you possibly mean by "industrial strength scripting language"?

When I hear about an "industrial strength" tool, I mostly infer that 
the tool:

 - spurs low-level code (instead of high-level meaning),
 - is moderately difficult to learn (or even use),
 - is extremely difficult to implement,
 - has paid-for support.



expressiveness is a priority (I borrow many features from scripting 
languages, like JavaScript, Scheme, ...). the language aims to have a 
high-level of dynamic abilities in most areas as well (it supports 
dynamic types, prototype OO, lexical closures, scope delegation, ...).



learning curve or avoiding implementation complexity were not huge 
concerns (the main concession I make to learning curve is that it is in 
many regards "fairly similar" to current mainstream languages, so if a 
person knows C++ or C# or similar, they will probably understand most of 
it easily enough).


the main target audience is generally people who already know C and C++ 
(and who will probably keep using them as well). so, the language is 
mostly intended to be used mixed with C and C++ codebases. the default 
syntax is more ActionScript-like, but Java/C# style declaration syntax 
may also be used (the only significant syntax differences are those 
related to the language's JavaScript heritage, and the use of "as" and 
"as!" operators for casts in place of C-style cast syntax).


generally, its basic design is intended to be a bit less obtuse than C 
or C++ though (the core syntax is more like that in Java and 
ActionScript in most regards, and more advanced features are intended 
mostly for special cases).



the VM is intended to be free, and I currently have it under the MIT 
license, but I don't currently have any explicit plans for "support". it 
is more of a "use it if you want" proposition, provided "as-is", and so on.


it is currently "given on request via email", mostly due to my server 
being offline and probably will be for a while (it is currently 1600 
miles away, and my parents don't know how to fix it...).



but, what I mostly meant was that it is designed in such a way to 
hopefully deal acceptably well with writing largish code-bases (like, 
supporting packages/namespaces and importing and so on), and should 
hopefully be competitive performance-wise with similar-class languages 
(still needs a bit more work on this front, namely to try to get 
performance to be more like Java, C#, or C++ and less like Python).


as-is, performance is less of a critical failing though, since one can 
put most performance critical code in C land and work around the weak 
performance somewhat (and, also, my projects are currently more bound by 
video-card performance than CPU performance as well).



in a few cases, things were done which favored performance over strict 
ECMA-262 conformance though (most notably, there are currently 
differences regarding default floating-point precision and similar, due 
mostly to the VM presently needing to box doubles, and generally double 
precision being unnecessary, ... however, the VM will use double 
precision if it is used explicitly).




If you meant something more positive, I think Lua is a good candidate:
 - Small (and hopefully reliable) tools.
 - Fast implementations.
 - Widely used in the gaming industry.
 - Good C FFI.
 - Spurs quite higher-level meaning.



Lua is small, and fairly fast (by scripting language terms).

its use in the gaming industry is moderate (it still faces competition 
against several other languages, namely Python, Scheme, and various 
engine-specific languages).


not everyone (myself included) is entirely fond of its Pascal-ish syntax 
though.


I also have doubts how well it will hold up to large-scale codebases though.


its native C FFI is "moderate" (in that it could be a lot worse), but 
AFAIK most of its ease of use here comes from the common use of SWIG 
(since SWIG shaves away most need for manually-written boilerplate).


the SWIG strategy though is itself a tradeoff IMO, since it requires 
some special treatment on the part of the headers, and works by 
producing intermediate glue code.


similarly, it doesn't address the matter of potential semantic 
mismatches between the languages (so the interfaces tend to be fairly 
basic).



in my case, a similar system to SWIG is directly supported by the VM, 
does not generally require boilerplate code (but does require any 
symbols to be DLL exports on Windows), and the FFI is m

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Loup Vaillant


BGB wrote:

there is also, at this point, a reasonable lack of "industrial strength
scripting languages".
there are a few major "industrial strength" languages (C, C++, Java, C#,
etc...), and a number of scripting languages (Python, Lua, JavaScript,
...), but not generally anything to "bridge the gap" (combining the
relative dynamic aspects and easy of use of a scripting language, with
the power to "get stuff done" as in a more traditional language).


What could you possibly mean by "industrial strength scripting language"?

When I hear about an "industrial strength" tool, I mostly infer that the 
tool:

 - spurs low-level code (instead of high-level meaning),
 - is moderately difficult to learn (or even use),
 - is extremely difficult to implement,
 - has paid-for support.

If you meant something more positive, I think Lua is a good candidate:
 - Small (and hopefully reliable) tools.
 - Fast implementations.
 - Widely used in the gaming industry.
 - Good C FFI.
 - Spurs quite higher-level meaning.

Loup.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 3/1/2012 8:04 AM, Reuben Thomas wrote:

On 1 March 2012 15:02, Julian Leviston  wrote:

Is this one of the aims?

It doesn't seem to be, which is sad, because however brilliant the
ideas you can't rely on other people to get them out for you.


this is part of why I am personally trying to work more to develop 
"products" than doing pure research, and focusing more on trying to 
"improve the situation" (by hopefully increasing the number of viable 
options) rather than "remake the world".


there is also, at this point, a reasonable lack of "industrial strength 
scripting languages".
there are a few major "industrial strength" languages (C, C++, Java, C#, 
etc...), and a number of scripting languages (Python, Lua, JavaScript, 
...), but not generally anything to "bridge the gap" (combining the 
relative dynamic aspects and easy of use of a scripting language, with 
the power to "get stuff done" as in a more traditional language).


a partial reason I suspect:
many script languages don't scale well (WRT either performance or 
usability);
many script languages have jokingly bad FFI's, combined with a lack of 
good native libraries;

...


or such...

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Reuben Thomas

On 1 March 2012 15:02, Julian Leviston  wrote:
> Is this one of the aims?

It doesn't seem to be, which is sad, because however brilliant the
ideas you can't rely on other people to get them out for you.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Julian Leviston

Is this one of the aims?

Julian

On 01/03/2012, at 11:42 PM, Reuben Thomas wrote:

> The biggest challenge for FONC will not be to achieve good technical
> results, as it is stuffed with people who have a history of doing
> great work, and its results to date are already exciting, but to get
> those results into widespread use; I've seen no evidence that the
> principals have considered how and why they failed to do this in the
> past, nor that they've any ideas on how to avoid it this time around.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Reuben Thomas

On 1 March 2012 12:00, Igor Stasenko  wrote:
> Now if you take things like tcp/ip. How much changes/extensions over
> the years since first deployment of it you seen?
> The only noticeable one i know of is introduction of ipv6.

Yes, but you can say the same of HTTP. You're comparing apples with orchards.

> Just wanted to indicate that if www would base on simpler design
> principles at the very beginning,
> we would not wait 27 years till javascript will be mature enough to
> simulate linux on it.

The reason HTTP/HTML won is precisely because they were extremely
simple to start with. The reason that Smalltalk, Hypercard et al.
didn't is because their inventors didn't take account of what actually
makes systems successful socially, rather than popular with
individuals.

And I fail to see what bemoaning the current state of affairs (or even
the tendency of history to repeat itself) achieves. Noticing what goes
wrong and trying to fix it is a positive step.

The biggest challenge for FONC will not be to achieve good technical
results, as it is stuffed with people who have a history of doing
great work, and its results to date are already exciting, but to get
those results into widespread use; I've seen no evidence that the
principals have considered how and why they failed to do this in the
past, nor that they've any ideas on how to avoid it this time around.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Igor Stasenko

On 1 March 2012 12:30, Reuben Thomas  wrote:
> On 1 March 2012 02:26, Igor Stasenko  wrote:
>> wonderful. so, in 5 years (put less if you want) i can be sure that my
>> app can run on every machine on any browser,
>> and i don't have to put "update your browser" warning.
>
> No, because in 5 years' time you will be wanting to do something
> different, and there will be a different immature technology to do it
> that hasn't yet been implemented on every machine. And of course
> there's a serious chance the browser will be on its way out by then
> (see how things are done on mobile platforms).
>
> 10 years ago we'd've been having the same conversation about Java.
> Today Java is still very much alive, and lots of people are getting
> things done with it.
>
> 5 years ago Flash might've been mentioned. Ditto.
>
Yeah.. all of the above resembling same cycle:
  initial stage - small, good and promising,
  becoming mainstream - growing, trying to fit everyone's needs until eventually
  turning into walking zombie - buried under tons of requirements and
standards and extensions.
And i bet that JavaScript will not be an exception.

Now if you take things like tcp/ip. How much changes/extensions over
the years since first deployment of it you seen?
The only noticeable one i know of is introduction of ipv6.

>> As to me, this language is not good enough to serve at such level.
>> From this point, it is inherently not complete and never will be, and
>> will always stand between you and your goals.
>
> If you're sufficiently determined, you'll manage to get nothing done
> whatever the technology on offer.
>
Oh, i am not arguing that we have to rely on what is available.
Just wanted to indicate that if www would base on simpler design
principles at the very beginning,
we would not wait 27 years till javascript will be mature enough to
simulate linux on it.

> --
> http://rrt.sc3d.org
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc



-- 
Best regards,
Igor Stasenko.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Reuben Thomas

On 1 March 2012 02:26, Igor Stasenko  wrote:
> wonderful. so, in 5 years (put less if you want) i can be sure that my
> app can run on every machine on any browser,
> and i don't have to put "update your browser" warning.

No, because in 5 years' time you will be wanting to do something
different, and there will be a different immature technology to do it
that hasn't yet been implemented on every machine. And of course
there's a serious chance the browser will be on its way out by then
(see how things are done on mobile platforms).

10 years ago we'd've been having the same conversation about Java.
Today Java is still very much alive, and lots of people are getting
things done with it.

5 years ago Flash might've been mentioned. Ditto.

> As to me, this language is not good enough to serve at such level.
> From this point, it is inherently not complete and never will be, and
> will always stand between you and your goals.

If you're sufficiently determined, you'll manage to get nothing done
whatever the technology on offer.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-03-01 Thread Anatoly Levenchuk

The same things are at a Very High Level computing (beyond application
boundary at enterprise-wide level, and especially beyond enterprise boundary
at business eco-systems level). There are "BPMN engines", "issue trackers",
"project management systems", "document management/workflow systems", etc..
And when you try to perform workflow/process/case execution of something
that need to be executed on all this "engines" mess, you have a huge
problems: too many high level execution paradigms (project, process, case
management, complex event management, etc.), too few good architectures and
tools to do this.

 

I think that scalability should go not only from hardware to "application as
desktop publishing" level but to support of enterprise architecture and
beyond (business eco-system architecture with federated enterprises). SOA
ideas is definitely not helpful here in its current "enterprise bus" state.

 

I consider programming, modeling and ontologizing from CPU hardware up to a
business eco-system level the same discipline and transfer from
programming/modeling/ontologizing-in-the-small to the same-in-the-large as
one of urgent needs. We should generalize concept of external execution to
preserve it meaning from hardware CPU core to OS/browser/distributed
application level to extended enterprise (network of hundreds of enterprises
that perform complex industrial projects like nuclear power station design
and construction).

 

Best regards,

Anatoly Levenchuk

 

From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan
Kay
Sent: Thursday, March 01, 2012 3:10 AM
To: Duncan Mak; Fundamentals of New Computing
Subject: Re: [fonc] Error trying to compile COLA

 

Hi Duncan

 

The short answers to these questions have already been given a few times on
this list. But let me try another direction to approach this.

 

The first thing to notice about the overlapping windows interface "personal
computer experience" is that it is logically independent of the
code/processes running underneath. This means (a) you don't have to have a
single religion "down below" (b) the different kinds of things that might be
running can be protected from each other using the address space mechanisms
of the CPU(s), and (c) you can think about allowing "outsiders" to do pretty
much what they want to create a really scalable really expandable WWW.

 

If you are going to put a "browser app" on an "OS", then the "browser" has
to be a mini-OS, not an app. 

 

But "standard apps" are a bad idea (we thought we'd gotten rid of them in
the 70s) because what you really want to do is to integrate functionality
visually and operationally using the overlapping windows interface, which
can safely get images from the processes and composite them on the screen.
(Everything is now kind of "super-desktop-publishing".) An "app" is now just
a kind of integration.

 

But the route that was actually taken with the WWW and the browser was in
the face of what was already being done.

 

Hypercard existed, and showed what a WYSIWYG authoring system for end-users
could do. This was ignored.

 

Postscript existed, and showed that a small interpreter could be moved
easily from machine to machine while retaining meaning. This was ignored.

 

And so forth.

 

19 years later we see various attempts at inventing things that were already
around when the WWW was tacked together.

 

But the thing that is amazing to me is that in spite of the almost universal
deployment of it, it still can't do what you can do on any of the machines
it runs on. And there have been very few complaints about this from the
mostly naive end-users (and what seem to be mostly naive computer folks who
deal with it).

 

Some of the blame should go to Apple and MS for not making real OSs for
personal computers -- or better, going the distance to make something better
than the old OS model. In either case both companies blew doing basic
protections between processes. 

 

On the other hand, the WWW and first browsers were originally done on
workstations that had stronger systems underneath -- so why were they so
blind?

 

As an aside I should mention that there have been a number of attempts to do
something about "OS bloat". Unix was always "too little too late" but its
one outstanding feature early on was its tiny kernel with a design that
wanted everything else to be done in "user-mode-code". Many good things
could have come from the later programmers of this system realizing that
being careful about dependencies is a top priority. (And you especially do
not want to have your dependencies handled by a central monolith, etc.)

 

So, this gradually turned into an awful mess. But Linus went back to square
one and redefined a tiny kernel again -- the realization here

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread David Smith

ut Javascript isn't fast
> enough to do the particle system. But why can't we just download the
> particle system and run it in a safe address space? The browser people
> don't yet understand that this is what they should have allowed in the
> first place. So right now there is only one route for this (and a few years
> ago there were none) -- and that is Native Client on Google Chrome.
>
>  But Google Chrome is only 13% penetrated, and the other browser fiefdoms
> don't like NaCl. Google Chrome is an .exe file so teachers can't
> download it (and if they could, they could download the Etoys plugin).
>
> Just in from browserland ... there is now -- 19 years later -- an allowed
> route to put samples in your machine's sound buffer that works on some of
> the browsers.
>
> Holy cow folks!
>
> Alan
>
>
>
>   --
> *From:* Duncan Mak 
> *To:* Alan Kay ; Fundamentals of New Computing <
> fonc@vpri.org>
> *Sent:* Wednesday, February 29, 2012 11:50 AM
>
> *Subject:* Re: [fonc] Error trying to compile COLA
>
> Hello Alan,
>
> On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay  wrote:
>
> For example, one of the many current day standards that was dismissed
> immediately is the WWW (one could hardly imagine more of a mess).
>
>
> I was talking to a friend the other day about the conversations going on
> in this mailing list - my friend firmly believes that the Web (HTTP) is one
> of the most important innovations in recent decades.
>
> One thing he cites as innovative is a point that I think TimBL mentions
> often: that the Web was successful (and not prior hypertext systems)
> because it allowed for broken links.
>
> Is that really a good architectural choice? If not, is there a reason why
> the Web succeeded, where previous hypertext systems failed? Is it only
> because of "pop culture"?
>
> What are the architectural flaws of the current Web? Is there anything
> that could be done to make it better, in light of these flaws?
>
> --
> Duncan.
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Igor Stasenko

On 1 March 2012 03:59, Reuben Thomas  wrote:
> On 1 March 2012 01:40, Igor Stasenko  wrote:
>> On 1 March 2012 02:46, Reuben Thomas  wrote:
>>> On 29 February 2012 23:09, Alan Kay  wrote:
>>>
>>> [Recapitulation snipped]
>>>
 So, this gradually turned into an awful mess. But Linus went back to square
 one
>>>
>>> Not really, it was just a reimplementation of the same thing on cheap
>>> modern hardware.
>>>
 But there is still the browser and Javascript. But Javascript isn't fast
 enough to do the particle system.
>>>
>>> Javascript is plenty fast enough to run a simulated x86 booting Linux
>>> and running applications:
>>>
>>> http://bellard.org/jslinux/
>>>
>>> Granted, it shouldn't be necessary to go via Javascript.
>>>
  But Google Chrome is only 13% penetrated,
>>>
>>> ~40% these days. Things move fast.
>>>
>>> The degree to which the "mess" we're in is avoidable (or, I'd go
>>> further, even undesirable) is also exaggerated.
>>>
>>
>> But this is not about penetration.
>
> Alan seemed to think penetration mattered; I had some good news.
>
>> It is clear, as to me, that NaCl is the only way to make web better
>> living place.
>> You say Javascript is fast?
>> Now can you tell me, how i can run and manage multiple parallel threads in 
>> it?
>
> Like this:
>
> http://www.sitepoint.com/javascript-threading-html5-web-workers/
>
wonderful. so, in 5 years (put less if you want) i can be sure that my
app can run on every machine on any browser,
and i don't have to put "update your browser" warning.
What a relief!


> Don't complain that the future is late arriving. The future is already
> here, perhaps just not quite in the shape we hoped. And the big news
> is that it never will be quite in the shape we'd like; there will be
> no complete solution.
>
The big news is that mileage can be much shorter if you go right way.
Once half-baked JavaScript now evolved into a full-fledged virtual machine.
I am so happy about it. But the problem is that it is not  virtual machine.
And not just a virtual machine.
Can i ask, why i forced to use javascript as a modern assembly language for web?
As to me, this language is not good enough to serve at such level.
From this point, it is inherently not complete and never will be, and
will always stand between you and your goals.

> Rousseau got this right over 200 years ago: his book "The Social
> Contract", which tried to do for the organisation of society what FONC
> is trying to do for computing, took for its starting point "people as
> they are and laws as they might be". Most visionaries would do well to
> copy that first part.
>
> --
> http://rrt.sc3d.org
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc



-- 
Best regards,
Igor Stasenko.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread BGB

people don't yet understand that this is what they should have allowed 
in the first place. So right now there is only one route for this (and 
a few years ago there were none) -- and that is Native Client on 
Google Chrome.




JavaScript has been getting faster though.
in recent years, Mozilla has put a lot of effort into exploring 
newer/faster JITs.

granted, this is not the only drawback with JS though.


in my own "vision", C is also part of the picture, although I had 
generally imagined in a VM managed form, probably with some amount of 
(potentially not strictly free) background-checking for "untrusted" code 
(in part, the pointers could also be "fake" as well, very possibly they 
would also be boxed in many cases, as in my current VM).


potentially, the C code could also be disallowed from holding a pointer 
to any address not either in "safe" areas, or outside of its known 
authority range (pointers could be validated either during an untrusted 
load, or throw an exception on the first attempt to access them). with 
luck, something like this could be mostly optimized away by the JIT (by 
attempting to prove cases where such checks or boxing is unnecessary).


ironically, I have often wanted a lot of these sorts of checks as a 
debugging feature as well, mostly to help trap things like accidental 
array overruns, ...


granted, if done well, however, this could also allow the implementation 
to use either an NaCl style strategy (a restricted address space and 
other checks), or use other possible strategies, without significantly 
impacting the code's performance or functionality (a bytecode could be 
used, with it being left up to the JIT how to go about compiling it to 
native code and performing any relevant security checks).



I haven't done much with C in a VM though, partly because this is a more 
complex problem and less immediately relevant (to myself) than some 
other stuff I am working on (it is along the same lines as trying to get 
my FFI tools to support C++ features, ...).




 But Google Chrome is only 13% penetrated, and the other browser 
fiefdoms don't like NaCl. Google Chrome is an .exe file so 
teachers can't download it (and if they could, they could download the 
Etoys plugin).


Just in from browserland ... there is now -- 19 years later -- an 
allowed route to put samples in your machine's sound buffer that works 
on some of the browsers.


Holy cow folks!



yep.



Alan




*From:* Duncan Mak 
*To:* Alan Kay ; Fundamentals of New
Computing 
*Sent:* Wednesday, February 29, 2012 11:50 AM
*Subject:* Re: [fonc] Error trying to compile COLA

Hello Alan,

On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay mailto:alan.n...@yahoo.com>> wrote:

For example, one of the many current day standards that was
dismissed immediately is the WWW (one could hardly imagine
more of a mess).


I was talking to a friend the other day about the conversations
going on in this mailing list - my friend firmly believes that the
Web (HTTP) is one of the most important innovations in recent decades.

One thing he cites as innovative is a point that I think TimBL
mentions often: that the Web was successful (and not prior
hypertext systems) because it allowed for broken links.

Is that really a good architectural choice? If not, is there a
reason why the Web succeeded, where previous hypertext systems
failed? Is it only because of "pop culture"?

What are the architectural flaws of the current Web? Is there
anything that could be done to make it better, in light of these
flaws?

-- 
Duncan.





___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Reuben Thomas

On 1 March 2012 01:40, Igor Stasenko  wrote:
> On 1 March 2012 02:46, Reuben Thomas  wrote:
>> On 29 February 2012 23:09, Alan Kay  wrote:
>>
>> [Recapitulation snipped]
>>
>>> So, this gradually turned into an awful mess. But Linus went back to square
>>> one
>>
>> Not really, it was just a reimplementation of the same thing on cheap
>> modern hardware.
>>
>>> But there is still the browser and Javascript. But Javascript isn't fast
>>> enough to do the particle system.
>>
>> Javascript is plenty fast enough to run a simulated x86 booting Linux
>> and running applications:
>>
>> http://bellard.org/jslinux/
>>
>> Granted, it shouldn't be necessary to go via Javascript.
>>
>>>  But Google Chrome is only 13% penetrated,
>>
>> ~40% these days. Things move fast.
>>
>> The degree to which the "mess" we're in is avoidable (or, I'd go
>> further, even undesirable) is also exaggerated.
>>
>
> But this is not about penetration.

Alan seemed to think penetration mattered; I had some good news.

> It is clear, as to me, that NaCl is the only way to make web better
> living place.
> You say Javascript is fast?
> Now can you tell me, how i can run and manage multiple parallel threads in it?

Like this:

http://www.sitepoint.com/javascript-threading-html5-web-workers/

Don't complain that the future is late arriving. The future is already
here, perhaps just not quite in the shape we hoped. And the big news
is that it never will be quite in the shape we'd like; there will be
no complete solution.

Rousseau got this right over 200 years ago: his book "The Social
Contract", which tried to do for the organisation of society what FONC
is trying to do for computing, took for its starting point "people as
they are and laws as they might be". Most visionaries would do well to
copy that first part.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Igor Stasenko

On 1 March 2012 02:46, Reuben Thomas  wrote:
> On 29 February 2012 23:09, Alan Kay  wrote:
>
> [Recapitulation snipped]
>
>> So, this gradually turned into an awful mess. But Linus went back to square
>> one
>
> Not really, it was just a reimplementation of the same thing on cheap
> modern hardware.
>
>> But there is still the browser and Javascript. But Javascript isn't fast
>> enough to do the particle system.
>
> Javascript is plenty fast enough to run a simulated x86 booting Linux
> and running applications:
>
> http://bellard.org/jslinux/
>
> Granted, it shouldn't be necessary to go via Javascript.
>
>>  But Google Chrome is only 13% penetrated,
>
> ~40% these days. Things move fast.
>
> The degree to which the "mess" we're in is avoidable (or, I'd go
> further, even undesirable) is also exaggerated.
>

But this is not about penetration. It is about the wrong approach.
The first application which i saw, which can do 'virtual boxing'
is running multiple instances of MS DOS on 386-based machine,
called DESQview (http://en.wikipedia.org/wiki/DESQview)
and i was quite amazed at that moment, that you can actually run two
different instances of operating system
(and of course arbitrary software on each of them), without even
realizing that they sharing single hardware box: CPU/Memory etc.

Now, it took 2011-1984  - 27 years! for industry to realize that
virtualization can be used for something else than boxing whole OS
to be able to run Linux on Windows or Windows on Linux...
What strikes me is that things like NaCl were doable from the very
beginning, back in 1995.
Instead, people invented javascript and invested a lot into it (and
keep investing) to make it faster, more secure , allow you to play
sounds /videos/3D graphics.
While desktop-based apps were able to do that from the beginning!

It is clear, as to me, that NaCl is the only way to make web better
living place.
You say Javascript is fast?
Now can you tell me, how i can run and manage multiple parallel threads in it?
Can you do it at all? And if not, lets wait for 10 more years till
people will implement it for us?

> --
> http://rrt.sc3d.org
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc

-- 
Best regards,
Igor Stasenko.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Reuben Thomas

On 29 February 2012 23:09, Alan Kay  wrote:

[Recapitulation snipped]

> So, this gradually turned into an awful mess. But Linus went back to square
> one

Not really, it was just a reimplementation of the same thing on cheap
modern hardware.

> But there is still the browser and Javascript. But Javascript isn't fast
> enough to do the particle system.

Javascript is plenty fast enough to run a simulated x86 booting Linux
and running applications:

http://bellard.org/jslinux/

Granted, it shouldn't be necessary to go via Javascript.

>  But Google Chrome is only 13% penetrated,

~40% these days. Things move fast.

The degree to which the "mess" we're in is avoidable (or, I'd go
further, even undesirable) is also exaggerated.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Max Orhai

el for migrating
> processes over a network. It was Unix only, but there was nothing about his
> design that required this.
>
> Cutting to the chase with a current day example. We made Etoys 15 years
> ago so children could learn about math, science, systems, etc. It has a
> particle system that allows many interesting things to be explored.
>
> Windows (especially) is so porous that SysAdmins (especially in school
> districts) will not allow teachers to download .exe files. This wipes out
> the Squeak plugin that provides all the functionality.
>
> But there is still the browser and Javascript. But Javascript isn't fast
> enough to do the particle system. But why can't we just download the
> particle system and run it in a safe address space? The browser people
> don't yet understand that this is what they should have allowed in the
> first place. So right now there is only one route for this (and a few years
> ago there were none) -- and that is Native Client on Google Chrome.
>
>  But Google Chrome is only 13% penetrated, and the other browser fiefdoms
> don't like NaCl. Google Chrome is an .exe file so teachers can't
> download it (and if they could, they could download the Etoys plugin).
>
> Just in from browserland ... there is now -- 19 years later -- an allowed
> route to put samples in your machine's sound buffer that works on some of
> the browsers.
>
> Holy cow folks!
>
> Alan
>
>
>
>   --
> *From:* Duncan Mak 
> *To:* Alan Kay ; Fundamentals of New Computing <
> fonc@vpri.org>
> *Sent:* Wednesday, February 29, 2012 11:50 AM
>
> *Subject:* Re: [fonc] Error trying to compile COLA
>
> Hello Alan,
>
> On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay  wrote:
>
> For example, one of the many current day standards that was dismissed
> immediately is the WWW (one could hardly imagine more of a mess).
>
>
> I was talking to a friend the other day about the conversations going on
> in this mailing list - my friend firmly believes that the Web (HTTP) is one
> of the most important innovations in recent decades.
>
> One thing he cites as innovative is a point that I think TimBL mentions
> often: that the Web was successful (and not prior hypertext systems)
> because it allowed for broken links.
>
> Is that really a good architectural choice? If not, is there a reason why
> the Web succeeded, where previous hypertext systems failed? Is it only
> because of "pop culture"?
>
> What are the architectural flaws of the current Web? Is there anything
> that could be done to make it better, in light of these flaws?
>
> --
> Duncan.
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Alan Kay

Hi Duncan

The short answers to these questions have already been given a few times on 
this list. But let me try another direction to approach this.

The first thing to notice about the overlapping windows interface "personal 
computer experience" is that it is logically independent of the code/processes 
running underneath. This means (a) you don't have to have a single religion 
"down below" (b) the different kinds of things that might be running can be 
protected from each other using the address space mechanisms of the CPU(s), and 
(c) you can think about allowing "outsiders" to do pretty much what they want 
to create a really scalable really expandable WWW.

If you are going to put a "browser app" on an "OS", then the "browser" has to 
be a mini-OS, not an app. 


But "standard apps" are a bad idea (we thought we'd gotten rid of them in the 
70s) because what you really want to do is to integrate functionality visually 
and operationally using the overlapping windows interface, which can safely get 
images from the processes and composite them on the screen. (Everything is now 
kind of "super-desktop-publishing".) An "app" is now just a kind of integration.

But the route that was actually taken with the WWW and the browser was in the 
face of what was already being done.

Hypercard existed, and showed what a WYSIWYG authoring system for end-users 
could do. This was ignored.

Postscript existed, and showed that a small interpreter could be moved easily 
from machine to machine while retaining meaning. This was ignored.

And so forth.

19 years later we see various attempts at inventing things that were already 
around when the WWW was tacked together.

But the thing that is amazing to me is that in spite of the almost universal 
deployment of it, it still can't do what you can do on any of the machines it 
runs on. And there have been very few complaints about this from the mostly 
naive end-users (and what seem to be mostly naive computer folks who deal with 
it).

Some of the blame should go to Apple and MS for not making real OSs for 
personal computers -- or better, going the distance to make something better 
than the old OS model. In either case both companies blew doing basic 
protections between processes. 


On the other hand, the WWW and first browsers were originally done on 
workstations that had stronger systems underneath -- so why were they so blind?


As an aside I should mention that there have been a number of attempts to do 
something about "OS bloat". Unix was always "too little too late" but its one 
outstanding feature early on was its tiny kernel with a design that wanted 
everything else to be done in "user-mode-code". Many good things could have 
come from the later programmers of this system realizing that being careful 
about dependencies is a top priority. (And you especially do not want to have 
your dependencies handled by a central monolith, etc.)


So, this gradually turned into an awful mess. But Linus went back to square one 
and redefined a tiny kernel again -- the realization here is that you do have 
to arbitrate basic resources of memory and process management, but you should 
allow everyone else to make the systems they need. This really can work well if 
processes can be small and interprocess communication fast (not the way Intel 
and Motorola saw it ...).


And I've also mentioned Popek's LOCUS system as a nice model for migrating 
processes over a network. It was Unix only, but there was nothing about his 
design that required this.

Cutting to the chase with a current day example. We made Etoys 15 years ago so 
children could learn about math, science, systems, etc. It has a particle 
system that allows many interesting things to be explored.

Windows (especially) is so porous that SysAdmins (especially in school 
districts) will not allow teachers to download .exe files. This wipes out the 
Squeak plugin that provides all the functionality.

But there is still the browser and Javascript. But Javascript isn't fast enough 
to do the particle system. But why can't we just download the particle system 
and run it in a safe address space? The browser people don't yet understand 
that this is what they should have allowed in the first place. So right now 
there is only one route for this (and a few years ago there were none) -- and 
that is Native Client on Google Chrome. 


 But Google Chrome is only 13% penetrated, and the other browser fiefdoms don't 
like NaCl. Google Chrome is an .exe file so teachers can't download it (and 
if they could, they could download the Etoys plugin).

Just in from browserland ... there is now -- 19 years later -- an allowed route 
to put samples in your machine's sound buffer that works on some of the 
browsers.

Holy cow folks!

Alan






>______

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread BGB

es more 
useful and desirable than the thing itself).

this also doesn't mean creating a "standard of non-standard" (some 
people have accused me of this, but I disagree), since often all that is 
needed is to create something in the form of the standard (and its 
common/expected behaviors), and everything will work as expected.

so, the essence is in the form, and in the behaviors, and not in the 
particular artifacts which are used to manifest it. so, one implements 
something according to a standard, but the standard doesn't really care 
whose code was used to implement it (or often, how things actually work 
internally, which is potentially different from one implementation to 
another).

sometimes, there are reasons to not just chase after the cult of "there 
is a library for that", but, annoyingly, many people start raving at the 
mere mention of doing some task without using whatever library/tool/... 
they think "should" be used in performing said task.

granted, in a few places, I have ended up resorting to relational-style 
systems instead (because, sadly, not every problem maps cleanly to a 
tree structure), but these are typically rarer (but are more common in 
my 3D engine and elsewhere, essentially my 3D engine amounts to a large 
and elaborate system of relational queries (and, no, without using an 
RDBMS), and only tangentially towards actually sending things out to the 
video card). there are pros and cons here.

or such...

Cheers,

Alan

--------------------
*From:* Loup Vaillant 
*To:* fonc@vpri.org
*Sent:* Wednesday, February 29, 2012 1:27 AM
*Subject:* Re: [fonc] Error trying to compile COLA

Alan Kay wrote:
> Hi Loup
>
> Very good question -- and tell your Boss he should support you!

Cool, thank you for your support.

> [...] One general argument is
> that "non-machine-code" languages are POLs of a weak sort, but
are more
> effective than writing machine code for most problems. (This was
quite
> controversial 50 years ago -- and lots of bosses forbade using any
> higher level language.)

I didn't thought about this historical perspective. I'll keep that in
mind, thanks.

> Companies (and programmers within) are rarely rewarded for
saving costs
> over the real lifetime of a piece of software [...]

I think my company is.  We make custom software, and most of the time
also get to maintain it.  Of course, we charge for both.  So, when we
manage to keep the maintenance cheap (less bugs, simpler code...),
we win.

However, we barely acknowledge it: much code I see is a technical debt
waiting to be paid, because the original implementer wasn't given the
time to do even a simple cleanup.

> An argument that resonates with some bosses is the "debuggable
> requirements/specifications -> ship the prototype and improve
it" whose
> benefits show up early on.

But of course.  I should have thought about it, thanks.

> [...] one of the most important POLs to be worked on are
> the ones that are for making POLs quickly.

This why I am totally thrilled by Ometa and Maru. I use them to point
out that programming languages can be much cheaper to implement than
most think they are.  It is difficult however to get past the idea
that
implementing a language (even a small, specialized one) is by
default a
huge undertaking.

Cheers,
Loup.
___
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Duncan Mak

Hello Alan,

On Tue, Feb 28, 2012 at 4:30 PM, Alan Kay  wrote:

> For example, one of the many current day standards that was dismissed
> immediately is the WWW (one could hardly imagine more of a mess).
>

I was talking to a friend the other day about the conversations going on in
this mailing list - my friend firmly believes that the Web (HTTP) is one of
the most important innovations in recent decades.

One thing he cites as innovative is a point that I think TimBL mentions
often: that the Web was successful (and not prior hypertext systems)
because it allowed for broken links.

Is that really a good architectural choice? If not, is there a reason why
the Web succeeded, where previous hypertext systems failed? Is it only
because of "pop culture"?

What are the architectural flaws of the current Web? Is there anything that
could be done to make it better, in light of these flaws?

-- 
Duncan.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Alan Kay

I think it is domain dependent -- for example, it is very helpful to have a 
debugger of some kind for a parser, but less so for a projection language like 
Nile. On the other hand, debuggers for making both of these systems are very 
helpful. Etoys doesn't have a debugger because the important state is mostly 
visible in the form of graphical objects. OTOH, having a capturing tracer (a la 
EXDAMS) could be nice for both reviewing and understanding complex interactions 
and also dealing with "unrepeatable events"

The topic of going from an idea for a useful POL to an actually mission usable 
POL is prime thesis territory.


Cheers,

Alan




>
> From: Loup Vaillant 
>To: fonc@vpri.org 
>Sent: Wednesday, February 29, 2012 5:43 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>Yes, I'm aware of that limitation.  I have the feeling however that
>IDEs and debuggers are overrated.  Sure, when dealing with a complex
>program in a complex language (say, tens of thousands of lines in C++),
>then sure, IDEs and debuggers are a must.  But I'm not sure their
>absence outweigh the simplicity potentially achieved with POLs. (I
>mean, I really don't know.  It could even be domain-dependent.)
>
>I agree however that having both (POLs + tools) would be much better,
>and is definitely worth pursuing.  I'll think about it.
>
>Loup.
>
>
>
>Alan Kay wrote:
>> With regard to your last point -- making POLs -- I don't think we are
>> there yet. It is most definitely a lot easier to make really powerful
>> POLs fairly quickly than it used to be, but we still don't have a nice
>> methodology and tools to automatically supply the IDE, debuggers, etc.
>> that need to be there for industrial-strength use.
>>
>> Cheers,
>>
>> Alan
>>
>>     *From:* Loup Vaillant 
>>     *To:* fonc@vpri.org
>>     *Sent:* Wednesday, February 29, 2012 1:27 AM
>>     *Subject:* Re: [fonc] Error trying to compile COLA
>>
>>     Alan Kay wrote:
>>      > Hi Loup
>>      >
>>      > Very good question -- and tell your Boss he should support you!
>>
>>     Cool, thank you for your support.
>>
>>
>>      > […] One general argument is
>>      > that "non-machine-code" languages are POLs of a weak sort, but
>>     are more
>>      > effective than writing machine code for most problems. (This was
>>     quite
>>      > controversial 50 years ago -- and lots of bosses forbade using any
>>      > higher level language.)
>>
>>     I didn't thought about this historical perspective. I'll keep that in
>>     mind, thanks.
>>
>>
>>      > Companies (and programmers within) are rarely rewarded for saving
>>     costs
>>      > over the real lifetime of a piece of software […]
>>
>>     I think my company is. We make custom software, and most of the time
>>     also get to maintain it. Of course, we charge for both. So, when we
>>     manage to keep the maintenance cheap (less bugs, simpler code…), we win.
>>
>>     However, we barely acknowledge it: much code I see is a technical debt
>>     waiting to be paid, because the original implementer wasn't given the
>>     time to do even a simple cleanup.
>>
>>
>>      > An argument that resonates with some bosses is the "debuggable
>>      > requirements/specifications -> ship the prototype and improve it"
>>     whose
>>      > benefits show up early on.
>>
>>     But of course. I should have thought about it, thanks.
>>
>>
>>      > […] one of the most important POLs to be worked on are
>>      > the ones that are for making POLs quickly.
>>
>>     This why I am totally thrilled by Ometa and Maru. I use them to point
>>     out that programming languages can be much cheaper to implement than
>>     most think they are. It is difficult however to get past the idea that
>>     implementing a language (even a small, specialized one) is by default a
>>     huge undertaking.
>>
>>     Cheers,
>>     Loup.
>>     ___
>>     fonc mailing list
>>    fonc@vpri.org <mailto:fonc@vpri.org>
>>     http://vpri.org/mailman/listinfo/fonc
>>
>>
>>
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Loup Vaillant

Yes, I'm aware of that limitation.  I have the feeling however that
IDEs and debuggers are overrated.  Sure, when dealing with a complex
program in a complex language (say, tens of thousands of lines in C++),
then sure, IDEs and debuggers are a must.  But I'm not sure their
absence outweigh the simplicity potentially achieved with POLs. (I
mean, I really don't know.  It could even be domain-dependent.)

I agree however that having both (POLs + tools) would be much better,
and is definitely worth pursuing.  I'll think about it.

Loup.

Alan Kay wrote:

With regard to your last point -- making POLs -- I don't think we are
there yet. It is most definitely a lot easier to make really powerful
POLs fairly quickly than it used to be, but we still don't have a nice
methodology and tools to automatically supply the IDE, debuggers, etc.
that need to be there for industrial-strength use.

Cheers,

Alan

*From:* Loup Vaillant 
*To:* fonc@vpri.org
*Sent:* Wednesday, February 29, 2012 1:27 AM
    *Subject:* Re: [fonc] Error trying to compile COLA

Alan Kay wrote:
 > Hi Loup
 >
 > Very good question -- and tell your Boss he should support you!

Cool, thank you for your support.

 > […] One general argument is
 > that "non-machine-code" languages are POLs of a weak sort, but
are more
 > effective than writing machine code for most problems. (This was
quite
 > controversial 50 years ago -- and lots of bosses forbade using any
 > higher level language.)

I didn't thought about this historical perspective. I'll keep that in
mind, thanks.

 > Companies (and programmers within) are rarely rewarded for saving
costs
 > over the real lifetime of a piece of software […]

I think my company is. We make custom software, and most of the time
also get to maintain it. Of course, we charge for both. So, when we
manage to keep the maintenance cheap (less bugs, simpler code…), we win.

However, we barely acknowledge it: much code I see is a technical debt
waiting to be paid, because the original implementer wasn't given the
time to do even a simple cleanup.

 > An argument that resonates with some bosses is the "debuggable
 > requirements/specifications -> ship the prototype and improve it"
whose
 > benefits show up early on.

But of course. I should have thought about it, thanks.

 > […] one of the most important POLs to be worked on are
 > the ones that are for making POLs quickly.

This why I am totally thrilled by Ometa and Maru. I use them to point
out that programming languages can be much cheaper to implement than
most think they are. It is difficult however to get past the idea that
implementing a language (even a small, specialized one) is by default a
huge undertaking.

Cheers,
Loup.
___
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Alan Kay

With regard to your last point -- making POLs -- I don't think we are there 
yet. It is most definitely a lot easier to make really powerful POLs fairly 
quickly  than it used to be, but we still don't have a nice methodology and 
tools to automatically supply the IDE, debuggers, etc. that need to be there 
for industrial-strength use.

Cheers,

Alan




>
> From: Loup Vaillant 
>To: fonc@vpri.org 
>Sent: Wednesday, February 29, 2012 1:27 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>Alan Kay wrote:
>> Hi Loup
>>
>> Very good question -- and tell your Boss he should support you!
>
>Cool, thank you for your support.
>
>
>> […] One general argument is
>> that "non-machine-code" languages are POLs of a weak sort, but are more
>> effective than writing machine code for most problems. (This was quite
>> controversial 50 years ago -- and lots of bosses forbade using any
>> higher level language.)
>
>I didn't thought about this historical perspective. I'll keep that in
>mind, thanks.
>
>
>> Companies (and programmers within) are rarely rewarded for saving costs
>> over the real lifetime of a piece of software […]
>
>I think my company is.  We make custom software, and most of the time
>also get to maintain it.  Of course, we charge for both.  So, when we
>manage to keep the maintenance cheap (less bugs, simpler code…), we win.
>
>However, we barely acknowledge it: much code I see is a technical debt
>waiting to be paid, because the original implementer wasn't given the
>time to do even a simple cleanup.
>
>
>> An argument that resonates with some bosses is the "debuggable
>> requirements/specifications -> ship the prototype and improve it" whose
>> benefits show up early on.
>
>But of course.  I should have thought about it, thanks.
>
>
>> […] one of the most important POLs to be worked on are
>> the ones that are for making POLs quickly.
>
>This why I am totally thrilled by Ometa and Maru. I use them to point
>out that programming languages can be much cheaper to implement than
>most think they are.  It is difficult however to get past the idea that
>implementing a language (even a small, specialized one) is by default a
>huge undertaking.
>
>Cheers,
>Loup.
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-29 Thread Loup Vaillant


Alan Kay wrote:

Hi Loup

Very good question -- and tell your Boss he should support you!


Cool, thank you for your support.



[…] One general argument is
that "non-machine-code" languages are POLs of a weak sort, but are more
effective than writing machine code for most problems. (This was quite
controversial 50 years ago -- and lots of bosses forbade using any
higher level language.)


I didn't thought about this historical perspective. I'll keep that in
mind, thanks.



Companies (and programmers within) are rarely rewarded for saving costs
over the real lifetime of a piece of software […]


I think my company is.  We make custom software, and most of the time
also get to maintain it.  Of course, we charge for both.  So, when we
manage to keep the maintenance cheap (less bugs, simpler code…), we win.

However, we barely acknowledge it: much code I see is a technical debt
waiting to be paid, because the original implementer wasn't given the
time to do even a simple cleanup.



An argument that resonates with some bosses is the "debuggable
requirements/specifications -> ship the prototype and improve it" whose
benefits show up early on.


But of course.  I should have thought about it, thanks.



[…] one of the most important POLs to be worked on are
the ones that are for making POLs quickly.


This why I am totally thrilled by Ometa and Maru. I use them to point
out that programming languages can be much cheaper to implement than
most think they are.  It is difficult however to get past the idea that
implementing a language (even a small, specialized one) is by default a
huge undertaking.

Cheers,
Loup.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Dale Schumacher

On Mon, Feb 27, 2012 at 5:23 PM, Charles Perkins  wrote:
> I think of the code size reduction like this:
>
> A book of logarithm tables may be hundreds of pages in length and yet the 
> equation producing the numbers can fit on one line.
>
> VPRI is exploring "runnable math" and is seeking key equations from which the 
> functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced.
>
> It's not about code compression, its about functionality expansion.

This reminds me of Gregory Chaitin's concept of algorithmic
complexity, leading to his results relating to compression, logical
irreducibility and "understanding" [1].

[1] G. Chaitin.  Meta Math! The Quest for Omega, Vintage Books 2006.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/28/2012 5:36 PM, Julian Leviston wrote:


On 29/02/2012, at 10:29 AM, BGB wrote:


On 2/28/2012 2:30 PM, Alan Kay wrote:
Yes, this is why the STEPS proposal was careful to avoid "the 
current day world".


For example, one of the many current day standards that was 
dismissed immediately is the WWW (one could hardly imagine more of a 
mess).




I don't think "the web" is entirely horrible:
HTTP basically works, and XML is "ok" IMO, and an XHTML variant could 
be ok.


Hypertext as a structure is not beautiful nor is it incredibly useful. 
Google exists because of how incredibly flawed the web is and if 
you look at their process for organising it, you start to find 
yourself laughing a lot. The general computing experience these days 
is an absolute shambles and completely crap. Computers are very very 
hard to use. Perhaps you don't see it - perhaps you're in the trees - 
you can't see the forest... but it's intensely bad.




I am not saying it is particularly "good", just that it is "ok" and "not 
completely horrible...".


it is, as are most things in life, generally adequate for what it does...

it could be better, and it could probably also be worse...


It's like someone crapped their pants and google came around and said 
hey you can wear gas masks if you like... when what we really need to 
do is clean up the crap and make sure there's a toilet nearby so that 
people don't crap their pants any more.




IMO, this is more when one gets into the SOAP / WSDL area...


granted, moving up from this, stuff quickly turns terrible (poorly 
designed, and with many "shiny new technologies" which are almost 
absurdly bad).



practically though, the WWW is difficult to escape, as a system 
lacking support for this is likely to be rejected outright.


You mean like email? A system that doesn't have anything to do with 
the WWW per se that is used daily by millions upon millions of people? 
:P I disagree intensely. In exactly the same was that facebook was 
taken up because it was a slightly less crappy version of myspace, 
something better than the web would be taken up in a heartbeat if it 
was accessible and obviously better.


You could, if you chose to, view this mailing group as a type of 
"living document" where you can peruse its contents through your email 
program... depending on what you see the web as being... maybe if you 
squint your eyes just the right way, you could envisage the web as 
simply being a means of sharing information to other humans... and 
this mailing group could simply be a different kind of web...


I'd hardly say that email hasn't been a great success... in fact, I 
think email, even though it, too is fairly crappy, has been more of a 
success than the world wide web.




I don't think email and the WWW are mutually exclusive, by any means.

yes, one probably needs email as well, as well as probably a small 
mountain of other things, to make a viable end-user OS...



however, technically, many people do use email via webmail interfaces 
and similar.
nevermind that many people use things like "Microsoft Outlook Web 
Access" and similar.


so, it is at least conceivable that a future exists where people read 
their email via webmail and access usenet almost entirely via Google 
Groups and similar...


not that it would be necessarily a good thing though...



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Julian Leviston

On 29/02/2012, at 10:29 AM, BGB wrote:

> On 2/28/2012 2:30 PM, Alan Kay wrote:
>> 
>> Yes, this is why the STEPS proposal was careful to avoid "the current day 
>> world". 
>> 
>> For example, one of the many current day standards that was dismissed 
>> immediately is the WWW (one could hardly imagine more of a mess). 
>> 
> 
> I don't think "the web" is entirely horrible:
> HTTP basically works, and XML is "ok" IMO, and an XHTML variant could be ok.

Hypertext as a structure is not beautiful nor is it incredibly useful. Google 
exists because of how incredibly flawed the web is and if you look at their 
process for organising it, you start to find yourself laughing a lot. The 
general computing experience these days is an absolute shambles and completely 
crap. Computers are very very hard to use. Perhaps you don't see it - perhaps 
you're in the trees - you can't see the forest... but it's intensely bad.

It's like someone crapped their pants and google came around and said hey you 
can wear gas masks if you like... when what we really need to do is clean up 
the crap and make sure there's a toilet nearby so that people don't crap their 
pants any more.

> 
> granted, moving up from this, stuff quickly turns terrible (poorly designed, 
> and with many "shiny new technologies" which are almost absurdly bad).
> 
> 
> practically though, the WWW is difficult to escape, as a system lacking 
> support for this is likely to be rejected outright.

You mean like email? A system that doesn't have anything to do with the WWW per 
se that is used daily by millions upon millions of people? :P I disagree 
intensely. In exactly the same was that facebook was taken up because it was a 
slightly less crappy version of myspace, something better than the web would be 
taken up in a heartbeat if it was accessible and obviously better.

You could, if you chose to, view this mailing group as a type of "living 
document" where you can peruse its contents through your email program... 
depending on what you see the web as being... maybe if you squint your eyes 
just the right way, you could envisage the web as simply being a means of 
sharing information to other humans... and this mailing group could simply be a 
different kind of web...

I'd hardly say that email hasn't been a great success... in fact, I think 
email, even though it, too is fairly crappy, has been more of a success than 
the world wide web.

Julian

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/28/2012 2:30 PM, Alan Kay wrote:
Yes, this is why the STEPS proposal was careful to avoid "the current 
day world".


For example, one of the many current day standards that was dismissed 
immediately is the WWW (one could hardly imagine more of a mess).




I don't think "the web" is entirely horrible:
HTTP basically works, and XML is "ok" IMO, and an XHTML variant could be ok.

granted, moving up from this, stuff quickly turns terrible (poorly 
designed, and with many "shiny new technologies" which are almost 
absurdly bad).



practically though, the WWW is difficult to escape, as a system lacking 
support for this is likely to be rejected outright.



But the functionality plus more can be replaced in our "ideal world" 
with encapsulated confined migratory VMs ("Internet objects") as a 
kind of next version of Gerry Popek's LOCUS.


The browser and other storage confusions are all replaced by the 
simple idea of separating out the safe objects from the various modes 
one uses to send and receive them. This covers files, email, web 
browsing, search engines, etc. What is left in this model is just a UI 
that can integrate the visual etc., outputs from the various 
encapsulated VMs, and send them events to react to. (The original 
browser folks missed that a scalable browser is more like a kernel OS 
than an App)


it is possible.

in my case, I had mostly assumed file and message passing.
theoretically, script code could be passed along as well, but the 
problem with passing code is how to best ensure that things are kept secure.



in some of my own uses, an option is to throw a UID/GID+privileges 
system into the mix, but there are potential drawbacks with this 
(luckily, the performance impact seems to be relatively minor). granted, 
a more comprehensive system (making use of ACLs and/or "keyrings" could 
be potentially a little more costly, rather than simple UID/GID rights 
checking, but all this shouldn't be too difficult to mostly optimize 
away in most cases).


the big issue is mostly to set up all the security in a "fairly secure" way.

currently, by default, nearly everything defaults to requiring root 
access. unprivileged code would thus require interfaces to be exposed to 
it directly (probably via "setuid" functions). however, as-is, it is 
defeated by most application code defaulting to "root".


somehow though, I think I am probably the only person I know who thinks 
this system is "sane".


however, it did seem like it would probably be easier to set up and 
secure than one based on scoping and visibility.



otherwise, yeah, maybe one can provide a bunch of APIs, and "apps" can 
be mostly implemented as scripts which invoke these APIs?...




These are old ideas, but the vendors etc didn't get it ...



maybe:
browser vendors originally saw the browser merely as a document viewing 
app (rather than as a "platform").



support for usable network file systems and "applications which aren't 
raw OS binaries" are slow-coming.


AFAIK, the main current contenders in the network filesystem space are 
SMB2/CIFS and WebDAV.


possibly useful could be integrating things in a form which is not 
terrible, for example:

OS has a basic HTML layout engine (doesn't care where the data comes from);
the OS's VFS can directly access HTTP, ideally without having to "mount" 
things first;

...

in this case, the "browser" is essentially just a fairly trivial script, 
say:
creates a window, and binds an HTML layout object into a form with a few 
other widgets;
passes any HTTP requests to the OS's filesystem API, with the OS 
managing getting the contents from the servers.


a partial advantage then is that other apps may not have to deal with 
libraries or sockets or similar to get files from web-servers, and 
likewise shell utilities would work, by default, with web-based files.


"cp http://someserver/somefile ~/myfiles/"

or similar...


actually, IIRC, my OS project may have actually done this (or it was 
planned, either way). I do remember though that sockets were available 
as part of the filesystem (under "/dev/" somewhere), so no sockets API 
was needed (it was instead based on opening the socket and using 
"ioctl()" calls...).



side note: what originally killed my OS project was, at the time, 
reaching the conclusion that it wouldn't have been likely possible for 
me to compete on equal terms with Windows and Linux, rendering the 
effort pointless, vs instead developing purely in userspace. does bring 
up some interesting thoughts though.



or such...



Cheers,

Alan





----
*From:* Reuben Thomas 
*To:* Fundamentals of New Computing 
*Sent:* Tuesday, February 28, 2012 1

Re: [fonc] Error trying to compile COLA

Yes, this is why the STEPS proposal was careful to avoid "the current day 
world". 


For example, one of the many current day standards that was dismissed 
immediately is the WWW (one could hardly imagine more of a mess). 


But the functionality plus more can be replaced in our "ideal world" with 
encapsulated confined migratory VMs ("Internet objects") as a kind of next 
version of Gerry Popek's LOCUS. 

The browser and other storage confusions are all replaced by the simple idea of 
separating out the safe objects from the various modes one uses to send and 
receive them. This covers files, email, web browsing, search engines, etc. What 
is left in this model is just a UI that can integrate the visual etc., outputs 
from the various encapsulated VMs, and send them events to react to. (The 
original browser folks missed that a scalable browser is more like a kernel OS 
than an App)

These are old ideas, but the vendors etc didn't get it ...


Cheers,

Alan




>
> From: Reuben Thomas 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 28, 2012 1:01 PM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>On 28 February 2012 20:51, Niklas Larsson  wrote:
>>
>> But Linux contains much more duplication than drivers only, it
>> supports many filesystems, many networking protocols, and many
>> architectures of which only a few of each are are widely used. It also
>> contains a lot of complicated optimizations of operations that would
>> be unwanted in a simple, transparent OS.
>
>Absolutely. And many of these cannot be removed, because otherwise you
>cannot interoperate with the systems that use them. (A similar
>argument can be made for hardware if you want your OS to be widely
>usable, but the software argument is rather more difficult to avoid.)
>
>> Let's put a number on that: the first public
>> release of Linux, 0.01, contains 5929 lines i C-files and 2484 in
>> header files. I'm sure that is far closer to what a minimal viable OS
>> is than what current Linux is.
>
>I'm not sure that counts as "viable".
>
>A portable system will always have to cope with a wide range of
>hardware. Alan has already pointed to a solution to this: devices that
>come with their own drivers. At the very least, it's not unreasonable
>to assume something like the old Windows model, where drivers are
>installed with the device, rather than shipped with the OS. So that
>percentage of code can indeed be removed.
>
>More troublingly, an interoperable system will always have to cope
>with a wide range of file formats, network protocols &c. As FoNC has
>demonstrated with TCP/IP, implementations of these sometimes made much
>smaller, but many formats and protocols will not be susceptible to
>reimplementation, for technical, legal or simple lack of interest.
>
>As far as redundancy in the Linux model, then, one is left with those
>parts of the system that can either be implemented with less code
>(hopefully, a lot of it), or where there is already duplication (e.g.
>schedulers).
>
>Unfortunately again, one person's "little-used architecture" is
>another's bread and butter (and since old architectures are purged
>from Linux, it's a reasonable bet that there are significant numbers
>of users of each supported architecture), and one person's
>"complicated optimization" is another's essential performance boost.
>It's precisely due to heavy optimization of the kernel and libc that
>the basic UNIX programming model has remained stable for so long in
>Linux, while still delivering the performance of advanced hardware
>undreamed-of when UNIX was designed.
>
>-- 
>http://rrt.sc3d.org
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/28/2012 10:33 AM, Reuben Thomas wrote:

On 28 February 2012 16:41, BGB  wrote:

  - 1 order of magnitude is gained by removing feature creep.  I agree
   feature creep can be important.  But I also believe most feature
   belong to a long tail, where each is needed by a minority of users.
   It does matter, but if the rest of the system is small enough,
   adding the few features you need isn't so difficult any more.


this could help some, but isn't likely to result in an order of magnitude.

Example: in Linux 3.0.0, which has many drivers (and Linux is often
cited as being "mostly drivers"), actually counting the code reveals
about 55-60% in drivers (depending how you count). So that even with
only one hardware configuration, you'd save less than 50% of the code
size, i.e. a factor of 2 at very best.



yeah, kind of the issue here.

one can shave code, reduce redundancy, increase abstraction, ... but 
this will only buy so much.


then one can start dropping features, but how many can one drop and 
still have everything still work?...


one can be like, "well, maybe we will make something like MS-DOS, but in 
long-mode?" (IOW: single-big address space, with no user/kernel 
separation, or conventional processes, and all kernel functionality is 
essentially library functionality).



ok, how small can this be made?
maybe 50 kloc, assuming one is sparing with the drivers.


I once wrote an OS kernel (long-dead project, ended nearly a decade 
ago), going and running a line counter on the whole project, I get about 
84 kloc. further investigation: 44 kloc of this was due to a copy of 
NASM sitting in the apps directory (I tried to port NASM to my OS at the 
time, but it didn't really work correctly, very possibly due to a 
quickly kludged-together C library...).



so, a 40 kloc OS kernel, itself at the time bordering on "barely worked".

what sorts of HW drivers did it have: ATA / IDE, console, floppy, VESA, 
serial mouse, RS232, RTL8139. how much code as drivers: 11 kloc.


how about VFS: 5 kloc, which include (FS drivers): "BSHFS" (IIRC, a 
TFTP-like shared filesystem), FAT (12/16/32), RAMFS.


another 5 kloc goes into the network code, which included TCP/IP, ARP, 
PPP, and an HTTP client+server.


boot loader was 288 lines (ASM), "setup" was 792 lines (ASM).

boot loader: copies boot files ("setup.bin" and "kernel.sys") into RAM 
(in the low 640K). seems hard-coded for FAT12.


"setup" was mostly responsible for setting up the kernel (copying it to 
the desired address) and entering protected mode (jumping into the 
kernel). this is commonly called a "second-stage" loader, partly because 
it does a lot of stuff which is too bulky to do in the boot loader 
(which is limited to 512 bytes, whereas "setup" can be up to 32kB).


"setup" magic: Enable A20, load GDT, enter big-real mode, check for "MZ" 
and "PE" markers (kernel was PE/COFF it seems), copies kernel image to 
VMA base, pushes kernel entry point to stack, remaps IRQs, executes 
32-bit return (jumps into protected mode).


around 1/2 of the "setup" file is code for jumping between real and 
protected mode and for interfacing with VESA.


note: I was using PE/COFF for apps and libraries as well.
IIRC, I was using a naive process-based model at the time.


could a better HLL have made the kernel drastically smaller? I have my 
doubts...



add the need for maybe a compiler, ... and the line count is sure to get 
larger quickly.


based on my own code, one could probably get a basically functional C 
compiler in around 100 kloc, but maybe smaller could be possible (this 
would include the compiler+assembler+linker).


apps/... would be a bit harder.


in my case, the most direct path would be just dumping all of my 
existing libraries on top of my original OS project, and maybe dropping 
the 3D renderer (since it would be sort of useless without GPU support, 
OpenGL, ...). this would likely weigh in at around 750-800 kloc (but 
could likely be made into a self-hosting OS, since a C compiler would be 
included, and as well there is a C runtime floating around).


this is all still a bit over the stated limit.


maybe, one could try to get a functional GUI framework and some basic 
applications and similar in place (probably maybe 100-200 kloc more, at 
least).


probably, by this point, one is looking at something like a Windows 3.x 
style disk footprint (maybe using 10-15 MB of HDD space or so for all 
the binaries...).



granted, in my case, the vast majority of the code would be C, probably 
with a smaller portion of the OS and applications being written in 
BGBScript or similar...



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

As I mentioned, Smalltalk-71 was never implemented -- and rarely mentioned (but 
it was part of the history of Smalltalk so I put in a few words about it).

If we had implemented it, we probably would have cleaned up the look of it, and 
also some of the conventions. 

You are right that part of it is like a term rewriting system, and part of it 
has state (object state).

to ... do ... is a operation. The match is on everything between toand do

For example, the first line with "cons" in it does the "car" operation (which 
here is "hd").

The second line with "cons" in it does "replaca". The value of "hd" is being 
replaced by the value of "c". 

One of the struggles with this design was to try to make something almost as 
simple as LOGO, but that could do language extensions, simple AI backward 
chaining inferencing (like Winograd's block stacking problem), etc.

The turgid punctuations (as I mentioned in the history) were attempts to find 
ways to do many different kinds of matching.

So we were probably lucky that Smalltalk-72 came along  It's pattern 
matching was less general, but quite a bit could be done as far as driving an 
extensible interpreter with it.

However, some of these ideas were done better later. I think by Leler, and 
certainly by Joe Goguen, and others.

Cheers,

Alan


>
> From: Jakob Praher 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Sent: Tuesday, February 28, 2012 12:52 PM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>
>Dear Alan,
>
>Am 28.02.12 14:54, schrieb Alan Kay: 
>Hi Ryan
>>
>>
>>Check out Smalltalk-71, which was a design to do just what you suggest -- it 
>>was basically an attempt to combine some of my favorite languages of the time 
>>-- Logo and Lisp, Carl Hewitt's Planner, Lisp 70, etc.
do you have a detailled documentation of Smalltalk 71 somewhere? Something like 
a Smalltalk 71 for Smalltalk 80 programmers :-)
>In the early history of Smalltalk you mention it as 
>> It was a kind of parser with object-attachment that executed tokens 
>> directly. The Early History of Smalltalk From the examples I think that "do 
>> 'expr'" is evaluating expr by using previous "to 'ident' :arg1..:argN 
>> ".
>
>As an example "do 'factorial 3'" should  evaluate to 6 considering:
>
>to 'factorial' 0 is 1
>to 'factorial' :n do 'n*factorial n-1' The Early History of Smalltalk What 
>about arithmetic and precendence: What part of language was built into the 
>system? 
>- :var denote variables, whereas var denotes the instantiated value
of :var in the expr, e.g. :n vs 'n-1'
>- '' denote simple tokens (in the head) as well as expressions
(in the body)?
>- to, do are keywords
>- () can be used for precedence
>
>You described evaluation as straightforward pattern-matching.
>It somehow reminds me of a term rewriting system -  e.g 'hd' ('cons'
:a :b) '<-'  :c " is a structured term.
>I know rewriting systems which first parse into an abstract
representation (e.g. prefix form) and transforms on the abstract
syntax - whereas in Smalltalk 71 the concrete syntax seems to be
used in the rules.
>
>Also it seems redundant to both have:
>to 'hd' ('cons' :a :b) do 'a' 
>and
>to 'hd' ('cons' :a :b) '<-'  :c  do 'a <- c'
>
>Is this made to make sure that the left hand side of <- has to be
a hd (cons :a :b) expression?
>
>Best,
>Jakob
>
>
>
>>
>>This never got implemented because of "a bet" that turned into Smalltalk-72, 
>>which also did what you suggest, but in a less comprehensive way -- think of 
>>each object as a Lisp closure that could be sent a pointer to the message and 
>>could then parse-and-eval that. 
>>
>>
>>A key to scaling -- that we didn't try to do -- is "semantic typing" (which I 
>>think is discussed in some of the STEPS material) -- that is: to be able to 
>>characterize the meaning of what is needed and produced in terms of a 
>>description rather than a label. Looks like we won't get to that idea this 
>>time either.
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>
>>>
>>> From: Ryan Mitchley 
>>>To: fonc@vpri.org 
>>>Sent: Tuesday, February 28, 2012 12:57 AM
>>>Subject: Re: [fonc] Error trying to compile COLA
>>> 
>>>
>>> 
>>>On 27/02/2012 19:48, Tony Ga

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Reuben Thomas

On 28 February 2012 20:51, Niklas Larsson  wrote:
>
> But Linux contains much more duplication than drivers only, it
> supports many filesystems, many networking protocols, and many
> architectures of which only a few of each are are widely used. It also
> contains a lot of complicated optimizations of operations that would
> be unwanted in a simple, transparent OS.

Absolutely. And many of these cannot be removed, because otherwise you
cannot interoperate with the systems that use them. (A similar
argument can be made for hardware if you want your OS to be widely
usable, but the software argument is rather more difficult to avoid.)

> Let's put a number on that: the first public
> release of Linux, 0.01, contains 5929 lines i C-files and 2484 in
> header files. I'm sure that is far closer to what a minimal viable OS
> is than what current Linux is.

I'm not sure that counts as "viable".

A portable system will always have to cope with a wide range of
hardware. Alan has already pointed to a solution to this: devices that
come with their own drivers. At the very least, it's not unreasonable
to assume something like the old Windows model, where drivers are
installed with the device, rather than shipped with the OS. So that
percentage of code can indeed be removed.

More troublingly, an interoperable system will always have to cope
with a wide range of file formats, network protocols &c. As FoNC has
demonstrated with TCP/IP, implementations of these sometimes made much
smaller, but many formats and protocols will not be susceptible to
reimplementation, for technical, legal or simple lack of interest.

As far as redundancy in the Linux model, then, one is left with those
parts of the system that can either be implemented with less code
(hopefully, a lot of it), or where there is already duplication (e.g.
schedulers).

Unfortunately again, one person's "little-used architecture" is
another's bread and butter (and since old architectures are purged
from Linux, it's a reasonable bet that there are significant numbers
of users of each supported architecture), and one person's
"complicated optimization" is another's essential performance boost.
It's precisely due to heavy optimization of the kernel and libc that
the basic UNIX programming model has remained stable for so long in
Linux, while still delivering the performance of advanced hardware
undreamed-of when UNIX was designed.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Jakob Praher

Dear Alan,

Am 28.02.12 14:54, schrieb Alan Kay:
> Hi Ryan
>
> Check out Smalltalk-71, which was a design to do just what you suggest
> -- it was basically an attempt to combine some of my favorite
> languages of the time -- Logo and Lisp, Carl Hewitt's Planner, Lisp
> 70, etc.
do you have a detailled documentation of Smalltalk 71 somewhere?
Something like a Smalltalk 71 for Smalltalk 80 programmers :-)
In the early history of Smalltalk you mention it as

> It was a kind of parser with object-attachment that executed tokens
directly.

>From the examples I think that "do 'expr'" is evaluating expr by using
previous "to 'ident' :arg1..:argN ".

As an example "do 'factorial 3'" should  evaluate to 6 considering:

to 'factorial' 0 is 1
to 'factorial' :n do 'n*factorial n-1'

What about arithmetic and precendence: What part of language was built
into the system?
- :var denote variables, whereas var denotes the instantiated value of
:var in the expr, e.g. :n vs 'n-1'
- '' denote simple tokens (in the head) as well as expressions (in
the body)?
- to, do are keywords
- () can be used for precedence

You described evaluation as straightforward pattern-matching.
It somehow reminds me of a term rewriting system -  e.g 'hd' ('cons' :a
:b) '<-'  :c " is a structured term.
I know rewriting systems which first parse into an abstract
representation (e.g. prefix form) and transforms on the abstract syntax
- whereas in Smalltalk 71 the concrete syntax seems to be used in the rules.

Also it seems redundant to both have:
to 'hd' ('cons' :a :b) do 'a'
and
to 'hd' ('cons' :a :b) '<-'  :c  do 'a <- c'

Is this made to make sure that the left hand side of <- has to be a hd
(cons :a :b) expression?

Best,
Jakob

>
> This never got implemented because of "a bet" that turned into
> Smalltalk-72, which also did what you suggest, but in a less
> comprehensive way -- think of each object as a Lisp closure that could
> be sent a pointer to the message and could then parse-and-eval that. 
>
> A key to scaling -- that we didn't try to do -- is "semantic typing"
> (which I think is discussed in some of the STEPS material) -- that is:
> to be able to characterize the meaning of what is needed and produced
> in terms of a description rather than a label. Looks like we won't get
> to that idea this time either.
>
> Cheers,
>
> Alan
>
> 
> *From:* Ryan Mitchley 
> *To:* fonc@vpri.org
> *Sent:* Tuesday, February 28, 2012 12:57 AM
> *Subject:* Re: [fonc] Error trying to compile COLA
>
> On 27/02/2012 19:48, Tony Garnock-Jones wrote:
>>
>> My interest in it came out of thinking about integrating pub/sub
>> (multi- and broadcast) messaging into the heart of a language.
>> What would a Smalltalk look like if, instead of a strict unicast
>> model with multi- and broadcast constructed atop (via
>> Observer/Observable), it had a messaging model capable of
>> natively expressing unicast, anycast, multicast, and broadcast
>> patterns? 
>>
>
> I've wondered if pattern matching shouldn't be a foundation of
> method resolution (akin to binding with backtracking in Prolog) -
> if a multicast message matches, the "method" is invoked (with much
> less specificity than traditional method resolution by
> name/token). This is maybe closer to the biological model of a
> cell surface receptor.
>
> Of course, complexity is an issue with this approach (potentially
> NP-complete).
>
> Maybe this has been done and I've missed it.
>
>
> ___
> fonc mailing list
> fonc@vpri.org <mailto:fonc@vpri.org>
> http://vpri.org/mailman/listinfo/fonc
>
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Niklas Larsson

Den 28 februari 2012 18:33 skrev Reuben Thomas :
> On 28 February 2012 16:41, BGB  wrote:
>>>
>>>  - 1 order of magnitude is gained by removing feature creep.  I agree
>>>   feature creep can be important.  But I also believe most feature
>>>   belong to a long tail, where each is needed by a minority of users.
>>>   It does matter, but if the rest of the system is small enough,
>>>   adding the few features you need isn't so difficult any more.
>>>
>>
>> this could help some, but isn't likely to result in an order of magnitude.
>
> Example: in Linux 3.0.0, which has many drivers (and Linux is often
> cited as being "mostly drivers"), actually counting the code reveals
> about 55-60% in drivers (depending how you count). So that even with
> only one hardware configuration, you'd save less than 50% of the code
> size, i.e. a factor of 2 at very best.
>

But Linux contains much more duplication than drivers only, it
supports many filesystems, many networking protocols, and many
architectures of which only a few of each are are widely used. It also
contains a lot of complicated optimizations of operations that would
be unwanted in a simple, transparent OS.

And not much code is actually needed to make a basic Unix clone. Once
upon a time Linux was a couple of thousand lines of C code big and was
even then a functional OS, capable of running a Unix userland and soon
gaining the ability to bootstrap itself by running the build
environment for itself. Let's put a number on that: the first public
release of Linux, 0.01, contains 5929 lines i C-files and 2484 in
header files. I'm sure that is far closer to what a minimal viable OS
is than what current Linux is.

Niklas
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

Hi Reuben

Yep. One of the many "finesses" in the STEPS project was to point out that 
requiring OSs to have drivers for everything misses what being networked is all 
about. In a nicer distributed systems design (such as Popek's LOCUS), one would 
get drivers from the devices automatically, and they would not be part of any 
OS code count. Apple even did this in the early days of the Mac for its own 
devices, but couldn't get enough other vendors to see why this was a really big 
idea.

Eventually the OS melts away to almost nothing (as it did at PARC in the 70s).

Then the question starts to become "how much code has to be written to make the 
various functional parts that will be semi-automatically integrated to make 
'vanilla personal computing' " ?

Cheers,

Alan

>
> From: Reuben Thomas 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 28, 2012 9:33 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>On 28 February 2012 16:41, BGB  wrote:
>>>
>>>  - 1 order of magnitude is gained by removing feature creep.  I agree
>>>   feature creep can be important.  But I also believe most feature
>>>   belong to a long tail, where each is needed by a minority of users.
>>>   It does matter, but if the rest of the system is small enough,
>>>   adding the few features you need isn't so difficult any more.
>>>
>>
>> this could help some, but isn't likely to result in an order of magnitude.
>
>Example: in Linux 3.0.0, which has many drivers (and Linux is often
>cited as being "mostly drivers"), actually counting the code reveals
>about 55-60% in drivers (depending how you count). So that even with
>only one hardware configuration, you'd save less than 50% of the code
>size, i.e. a factor of 2 at very best.
>
>-- 
>http://rrt.sc3d.org
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

Hi Loup

Very good question -- and tell your Boss he should support you!

If your boss has a math or science background, this will be an easy sell 
because there are many nice analogies that hold, and also some good examples in 
computing itself.

The POL approach is generally good, but for a particular problem area could be 
as difficult as any other approach. One general argument is that 
"non-machine-code" languages are POLs of a weak sort, but are more effective 
than writing machine code for most problems. (This was quite controversial 50 
years ago -- and lots of bosses forbade using any higher level language.)

Four arguments against POLs are the difficulties of (a) designing them, (b) 
making them, (c) creating IDE etc tools for them, and (d) learning them. (These 
are similar to the arguments about using math and science in engineering, but 
are not completely bogus for a small subset of problems ...).

Companies (and programmers within) are rarely rewarded for saving costs over 
the real lifetime of a piece of software (similar problems exist in the climate 
problems we are facing).These are social problems, but part of real 
engineering. However, at some point life-cycle costs and savings will become 
something that is accounted and rewarded-or-dinged. 

An argument that resonates with some bosses is the "debuggable 
requirements/specifications -> ship the prototype and improve it" whose 
benefits show up early on. However, these quicker track processes will often be 
stressed for time to do a new POL.

This suggests that one of the most important POLs to be worked on are the ones 
that are for making POLs quickly. I think this is a huge important area and 
much needs to be done here (also a very good area for new PhD theses!).

Taking all these factors (and there are more), I think the POL and extensible 
language approach works best for really difficult problems that small numbers 
of really good people are hooked up to solve (could be in a company, and very 
often in one of many research venues) -- and especially if the requirements 
will need to change quite a bit, both from learning curve and quick response to 
the outside world conditions.

Here's where a factor of 100 or 1000 (sometimes even a factor of 10) less code 
will be qualitatively powerful.

Right now I draw a line at *100. If you can get this or more, it is worth 
surmounting the four difficulties listed above. If you can get *1000, you are 
in a completely new world of development and thinking.

Cheers,

Alan

>
> From: Loup Vaillant 
>To: fonc@vpri.org 
>Sent: Tuesday, February 28, 2012 8:17 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>Alan Kay wrote:
>> Hi Loup
>>
>> As I've said and written over the years about this project, it is not
>> possible to compare features in a direct way here.
>
>Yes, I'm aware of that.  The problem rises when I do advocacy. A
>response I often get is "but with only 20,000 lines, they gotta
>leave features out!".  It is not easy to explain that a point by
>point comparison is either unfair or flatly impossible.
>
>
>> Our estimate so far is that we are getting our best results from the
>> consolidated redesign (folding features into each other) and then from
>> the POLs. We are still doing many approaches where we thought we'd have
>> the most problems with LOCs, namely at "the bottom".
>
>If I got it, what you call "consolidated redesign" encompasses what I
>called "feature creep" and "good engineering principles" (I understand
>now that they can't be easily separated). I originally estimated that:
>
>- You manage to gain 4 orders of magnitude compared to current OSes,
>- consolidated redesign gives you roughly 2 of those  (from 200M to 2M),
>- problem oriented languages give you the remaining 2.(from 2M  to 20K)
>
>Did I…
>- overstated the power of problem oriented languages?
>- understated the benefits of consolidated redesign?
>- forgot something else?
>
>(Sorry to bother you with those details, but I'm currently trying to
>  convince my Boss to pay me for a PhD on the grounds that PoLs are
>  totally amazing, so I'd better know real fast If I'm being
>  over-confident.)
>
>Thanks,
>Loup.
>
>
>
>> Cheers,
>>
>> Alan
>>
>>
>>     *From:* Loup Vaillant 
>>     *To:* fonc@vpri.org
>>     *Sent:* Tuesday, February 28, 2012 2:21 AM
>>     *Subject:* Re: [fonc] Error trying to compile COLA
>>
>>     Originally, the VPRI claims to be able to do a system that's 10,000
>>     smaller than our current bloatware. That's going from roughly 200
>>     million lines to 20,000. (Or, as Alan Kay puts

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Reuben Thomas

On 28 February 2012 16:41, BGB  wrote:
>>
>>  - 1 order of magnitude is gained by removing feature creep.  I agree
>>   feature creep can be important.  But I also believe most feature
>>   belong to a long tail, where each is needed by a minority of users.
>>   It does matter, but if the rest of the system is small enough,
>>   adding the few features you need isn't so difficult any more.
>>
>
> this could help some, but isn't likely to result in an order of magnitude.

Example: in Linux 3.0.0, which has many drivers (and Linux is often
cited as being "mostly drivers"), actually counting the code reveals
about 55-60% in drivers (depending how you count). So that even with
only one hardware configuration, you'd save less than 50% of the code
size, i.e. a factor of 2 at very best.

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/28/2012 3:21 AM, Loup Vaillant wrote:

Originally,  the VPRI claims to be able to do a system that's 10,000
smaller than our current bloatware.  That's going from roughly 200
million lines to 20,000. (Or, as Alan Kay puts it, from a whole library
to a single book.) That's 4 orders of magnitude.

From the report, I made a rough break down of the causes for code
reduction.  It seems that

 - 1 order of magnitude is gained by removing feature creep.  I agree
   feature creep can be important.  But I also believe most feature
   belong to a long tail, where each is needed by a minority of users.
   It does matter, but if the rest of the system is small enough,
   adding the few features you need isn't so difficult any more.



this could help some, but isn't likely to result in an order of magnitude.

it is much the same as thinking:
"this OS running on a single HW configuration will eliminate nearly all 
of the code related to drivers";
very likely, it would eliminate a lot of the HW-specific parts, but much 
the "common" functionality may still need to be there.




 - 1 order of magnitude is gained by mere good engineering principles.
   In Frank for instance, there is _one_ drawing system, that is used
   for everywhere.  Systematic code reuse can go a long way.
 Another example is the  code I work with.  I routinely find
   portions whose volume I can divide by 2 merely by rewriting a couple
   of functions.  I fully expect to be able to do much better if I
   could refactor the whole program.  Not because I'm a rock star (I'm
   definitely not).  Very far from that.  Just because the code I
   maintain is sufficiently abysmal.



this is elimination of redundancy, which is where I figured one would 
have the most results.
I suspect that, at least on the small scale, programmers tend to reduce 
redundancy where possible.


on the macro-scale, it is still a bit of an issue, as apps will tend to 
implement their own versions of things.


consider, for example, said OS has a 3D FPS style game in it:
maybe, the VFS code can be shared with the kernel, and with other apps;
likewise for memory management, and things like reflection and types 
management;

...

one may still have a big chunk of code for the 3D renderer.
ok, this is factored out, maybe a lot is shared with the GUI subsystem 
(which now deals with things light texture management, lighting, 
materials and shaders, ...);

...


but, one has a problem: what functionality is moved out of the 3D engine 
into other components in turn makes the parts the functionality into 
more complex, and leaving the functionality in the 3D engine means it 
has to deal with it.


someone could be like "well, this engine doesn't really need shadows and 
normal mapping", but people will notice.


if people are instead like, "this OS will not have or allow any sort of 
3D games", people will likely not go for it.



I suspect, at best, all this is likely to result in around a 25-50% 
reduction.




 - 2 orders of magnitude are gained through the use of Problem Oriented
   Languages (instead of C or C++). As examples, I can readily recall:
+ Gezira vs Cairo(÷95)
+ Ometa  vs Lex+Yacc (÷75)
+ TCP-IP (÷93)
   So I think this is not exaggerated.



I suspect this may be over-estimating it a bit.
say, eliminating C and C++ "may" eliminate some amount of bulk, say, 
people endlessly re-rolling their own linked lists, or typing verbose 
syntax.


but, a 100x average-case seems a bit of a stretch, even for this.
likewise: one still needs the logic to run said POLs.

a bigger problem though could be that it could become 
counter-productive, if the overuse of POLs renders the code unworkable 
due either to very few people being able to understand the POLs, or 
change the code in them without catastrophic results, like "don't touch 
this or your whole system will blow up in your face".




Looked at it this way, it doesn't seems so impossible any more.  I
don't expect you to suddenly agree the "4 orders of magnitude" claim
(It still defies my intuition), but you probably disagree specifically
with one of my three points above.  Possible objections I can think of
are:

 - Features matter more than I think they do.
 - One may not expect the user to write his own features, even though
   it would be relatively simple.
 - Current systems may be not as badly written as I think they are.
 - Code reuse could be harder than I think.
 - The two orders of magnitude that seem to come from problem oriented
   languages may not come from _only_ those.  It could come from the
   removal of features, as well as better engineering principles,
   meaning I'm counting some causes twice.



possibly.

I think more likely that is that a few things will result:
each thing has an effect, but not nearly so much, say if each stage only 
works out to maybe on average 25-50%;
one runs into a diminishing-returns curve (making one thing smaller 
makes it harder to make some

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant

Alan Kay wrote:

Hi Loup

As I've said and written over the years about this project, it is not
possible to compare features in a direct way here.

Yes, I'm aware of that.  The problem rises when I do advocacy. A
response I often get is "but with only 20,000 lines, they gotta
leave features out!".  It is not easy to explain that a point by
point comparison is either unfair or flatly impossible.

Our estimate so far is that we are getting our best results from the
consolidated redesign (folding features into each other) and then from
the POLs. We are still doing many approaches where we thought we'd have
the most problems with LOCs, namely at "the bottom".

If I got it, what you call "consolidated redesign" encompasses what I
called "feature creep" and "good engineering principles" (I understand
now that they can't be easily separated). I originally estimated that:

- You manage to gain 4 orders of magnitude compared to current OSes,
- consolidated redesign gives you roughly 2 of those  (from 200M to 2M),
- problem oriented languages give you the remaining 2.(from 2M  to 20K)

Did I…
- overstated the power of problem oriented languages?
- understated the benefits of consolidated redesign?
- forgot something else?

(Sorry to bother you with those details, but I'm currently trying to
 convince my Boss to pay me for a PhD on the grounds that PoLs are
 totally amazing, so I'd better know real fast If I'm being
 over-confident.)

Thanks,
Loup.

Cheers,

Alan

*From:* Loup Vaillant 
    *To:* fonc@vpri.org
    *Sent:* Tuesday, February 28, 2012 2:21 AM
*Subject:* Re: [fonc] Error trying to compile COLA

Originally, the VPRI claims to be able to do a system that's 10,000
smaller than our current bloatware. That's going from roughly 200
million lines to 20,000. (Or, as Alan Kay puts it, from a whole library
to a single book.) That's 4 orders of magnitude.

 From the report, I made a rough break down of the causes for code
reduction. It seems that

- 1 order of magnitude is gained by removing feature creep. I agree
feature creep can be important. But I also believe most feature
belong to a long tail, where each is needed by a minority of users.
It does matter, but if the rest of the system is small enough,
adding the few features you need isn't so difficult any more.

- 1 order of magnitude is gained by mere good engineering principles.
In Frank for instance, there is _one_ drawing system, that is used
for everywhere. Systematic code reuse can go a long way.
Another example is the code I work with. I routinely find
portions whose volume I can divide by 2 merely by rewriting a couple
of functions. I fully expect to be able to do much better if I
could refactor the whole program. Not because I'm a rock star (I'm
definitely not). Very far from that. Just because the code I
maintain is sufficiently abysmal.

- 2 orders of magnitude are gained through the use of Problem Oriented
Languages (instead of C or C++). As examples, I can readily recall:
+ Gezira vs Cairo (÷95)
+ Ometa vs Lex+Yacc (÷75)
+ TCP-IP (÷93)
So I think this is not exaggerated.

Looked at it this way, it doesn't seems so impossible any more. I
don't expect you to suddenly agree the "4 orders of magnitude" claim
(It still defies my intuition), but you probably disagree specifically
with one of my three points above. Possible objections I can think of
are:

- Features matter more than I think they do.
- One may not expect the user to write his own features, even though
it would be relatively simple.
- Current systems may be not as badly written as I think they are.
- Code reuse could be harder than I think.
- The two orders of magnitude that seem to come from problem oriented
languages may not come from _only_ those. It could come from the
removal of features, as well as better engineering principles,
meaning I'm counting some causes twice.

Loup.

BGB wrote:
 > On 2/27/2012 10:08 PM, Julian Leviston wrote:
 >> Structural optimisation is not compression. Lurk more.
 >
 > probably will drop this, as arguing about all this is likely
pointless
 > and counter-productive.
 >
 > but, is there any particular reason for why similar rules and
 > restrictions wouldn't apply?
 >
 > (I personally suspect that similar applies to nearly all forms of
 > communication, including written and spoken natural language, and a
 > claim that some X can be expressed in Y units does seem a fair amount
 > like a compression-style claim).
 >
 >
 > but, anyways, here is a link to another article:
 > http://en.wikipedia.org/wiki/Shanno

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant


Julian Leviston wrote:

Two things spring out of this at me (inline):

On 28/02/2012, at 9:21 PM, Loup Vaillant wrote:


- Features matter more than I think they do.
- One may not expect the user to write his own features, even though
it would be relatively simple.


What about when using software becomes "writing" features - see etoys.
Is clicking and dragging tiles still "writing" software? :)


Good point.  By default, I think of building software and using
software as two separate activities (though we do use software to
implement others). But if some software is built in such a way that the
default use case is to extend it, then my assumption goes right out the
window, and my objection doesn't work.

I did expect however that building software could be made much easier
than it is right now, if only because 20 Kloc can be taught before the
end of high school.  Plus, some spreadsheet users already do this.




- Current systems may be not as badly written as I think they are.
- Code reuse could be harder than I think.


It's not that they're written badly, it's just that that so many years
on, no one has really understood some of the powerful ideas of
yesteryear. Even those powerful ideas allowed a certain level of
magnification... but the powerful ideas of these days in addition to the
past allow an incredibly large possibility of magnification of thought...


OK, "badly written" is probably too dismissal.  What I meant was more
along the line of "right now I can do better".  The thing is, I regard
the clarity and terseness of my own code as the default, While anything
worse "sucks".  (I don't know if I am able to perceive when code is
better than my own.)  Of course, even my own code tend to "suck" if
it's old enough.

So I know I should be more forgiving.  It's just that when I see a
nested "if" instead of a conjunction, empty "else" branches, or
assignment happy interfaces, I feel the urge to deny oxygen to the
brain that produced this code.

Loup.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

Hi Loup

As I've said and written over the years about this project, it is not possible 
to compare features in a direct way here. The aim is to make something that 
feels like "vanilla personal computing" to an end-user -- that can do "a lot" 
-- and limit ourselves to 20,000 lines of code. We picked "personal computing" 
for three main reasons (a) we had some experience with doing this the first 
time around at PARC (in a very small amount of code), (b) it is something that 
people experience everyday, so they will be able to have opinions without 
trying to do a laborious point by point comparison, and (c) we would fail if we 
had to reverse engineer typical renditions of this (i.e. MS or Linux) -- we 
needed to do our own design to have a chance at this.

Our estimate so far is that we are getting our best results from the 
consolidated redesign (folding features into each other) and then from the 
POLs. We are still doing many approaches where we thought we'd have the most 
problems with LOCs, namely at "the bottom".

Cheers,

Alan




>
> From: Loup Vaillant 
>To: fonc@vpri.org 
>Sent: Tuesday, February 28, 2012 2:21 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>Originally,  the VPRI claims to be able to do a system that's 10,000
>smaller than our current bloatware.  That's going from roughly 200
>million lines to 20,000. (Or, as Alan Kay puts it, from a whole library
>to a single book.) That's 4 orders of magnitude.
>
>From the report, I made a rough break down of the causes for code
>reduction.  It seems that
>
>- 1 order of magnitude is gained by removing feature creep.  I agree
>   feature creep can be important.  But I also believe most feature
>   belong to a long tail, where each is needed by a minority of users.
>   It does matter, but if the rest of the system is small enough,
>   adding the few features you need isn't so difficult any more.
>
>- 1 order of magnitude is gained by mere good engineering principles.
>   In Frank for instance, there is _one_ drawing system, that is used
>   for everywhere.  Systematic code reuse can go a long way.
>     Another example is the  code I work with.  I routinely find
>   portions whose volume I can divide by 2 merely by rewriting a couple
>   of functions.  I fully expect to be able to do much better if I
>   could refactor the whole program.  Not because I'm a rock star (I'm
>   definitely not).  Very far from that.  Just because the code I
>   maintain is sufficiently abysmal.
>
>- 2 orders of magnitude are gained through the use of Problem Oriented
>   Languages (instead of C or C++). As examples, I can readily recall:
>    + Gezira vs Cairo    (÷95)
>    + Ometa  vs Lex+Yacc (÷75)
>    + TCP-IP             (÷93)
>   So I think this is not exaggerated.
>
>Looked at it this way, it doesn't seems so impossible any more.  I
>don't expect you to suddenly agree the "4 orders of magnitude" claim
>(It still defies my intuition), but you probably disagree specifically
>with one of my three points above.  Possible objections I can think of
>are:
>
>- Features matter more than I think they do.
>- One may not expect the user to write his own features, even though
>   it would be relatively simple.
>- Current systems may be not as badly written as I think they are.
>- Code reuse could be harder than I think.
>- The two orders of magnitude that seem to come from problem oriented
>   languages may not come from _only_ those.  It could come from the
>   removal of features, as well as better engineering principles,
>   meaning I'm counting some causes twice.
>
>Loup.
>
>
>BGB wrote:
>> On 2/27/2012 10:08 PM, Julian Leviston wrote:
>>> Structural optimisation is not compression. Lurk more.
>> 
>> probably will drop this, as arguing about all this is likely pointless
>> and counter-productive.
>> 
>> but, is there any particular reason for why similar rules and
>> restrictions wouldn't apply?
>> 
>> (I personally suspect that similar applies to nearly all forms of
>> communication, including written and spoken natural language, and a
>> claim that some X can be expressed in Y units does seem a fair amount
>> like a compression-style claim).
>> 
>> 
>> but, anyways, here is a link to another article:
>> http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem
>> 
>>> Julian
>>> 
>>> On 28/02/2012, at 3:38 PM, BGB wrote:
>>> 
>>>> granted, I remain a little skeptical.
>>>> 
>>>> I think there is a bit of a difference though between, say, a log
>>>>

Re: [fonc] Error trying to compile COLA

Hi Ryan

Check out Smalltalk-71, which was a design to do just what you suggest -- it 
was basically an attempt to combine some of my favorite languages of the time 
-- Logo and Lisp, Carl Hewitt's Planner, Lisp 70, etc.

This never got implemented because of "a bet" that turned into Smalltalk-72, 
which also did what you suggest, but in a less comprehensive way -- think of 
each object as a Lisp closure that could be sent a pointer to the message and 
could then parse-and-eval that. 

A key to scaling -- that we didn't try to do -- is "semantic typing" (which I 
think is discussed in some of the STEPS material) -- that is: to be able to 
characterize the meaning of what is needed and produced in terms of a 
description rather than a label. Looks like we won't get to that idea this time 
either.

Cheers,

Alan




>
> From: Ryan Mitchley 
>To: fonc@vpri.org 
>Sent: Tuesday, February 28, 2012 12:57 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>
> 
>On 27/02/2012 19:48, Tony Garnock-Jones wrote:
>
>
>>My interest in it came out of thinking about integrating
  pub/sub (multi- and broadcast) messaging into the heart of a
  language. What would a Smalltalk look like if, instead of a
  strict unicast model with multi- and broadcast constructed
  atop (via Observer/Observable), it had a messaging model
  capable of natively expressing unicast, anycast, multicast,
  and broadcast patterns? 
>>
>I've wondered if pattern matching shouldn't be a foundation of
method resolution (akin to binding with backtracking in Prolog) - if
a multicast message matches, the "method" is invoked (with much less
specificity than traditional method resolution by name/token). This
is maybe closer to the biological model of a cell surface receptor.
>
>Of course, complexity is an issue with this approach (potentially
NP-complete).
>
>Maybe this has been done and I've missed it.
>
>
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Alexis Read

I've only been looking at Maru, but as I understand it Maru is supposed to
be an evolution of COLA (ie Coke), and both object and lambda language. The
self hosting is important in that it can be treated as a first order entity
in the system, and I believe it's the smallest self hosting system
available (650 loc when optimised). I think the current plan is to port
Nile/gezira to Maru, and do away with Nothing - Maru is flexible enough to
act as a VM, cross compiler etc.
On Feb 28, 2012 11:35 AM, "Martin Baldan"  wrote:

> Guys, there are so much lines of inquiry in this thread I'm getting lost.
> Here's a little summary.
>
>
>
>
>
> [message]
> Author: Julian Leviston 
> http://vpri.org/mailman/private/fonc/2012/003081.html
>
> As I understand it, Frank is an experiment that is an extended version of
> DBJr that sits atop lesserphic, which sits atop gezira which sits atop
> nile, which sits atop maru all of which which utilise ometa and the
> "worlds" idea.
>
> If you look at the http://vpri.org/html/writings.php page you can see a
> pattern of progression that has emerged to the point where Frank exists.
> From what I understand, maru is the finalisation of what began as pepsi and
> coke. Maru is a simple s-expression language, in the same way that pepsi
> and coke were. In fact, it looks to have the same syntax. Nothing is the
> layer underneath that is essentially a symbolic computer - sitting between
> maru and the actual machine code (sort of like an LLVM assembler if I've
> understood it correctly).
> [..]
> http://www.vpri.org/vp_wiki/index.php/Main_Page
>
> On the bottom of that page, you'll see a link to the tinlizzie site that
> references "experiment" and the URL has dbjr in it... as far as I
> understand it, this is as much frank as we've been shown.
>
> http://tinlizzie.org/dbjr/
>
> [/message]
>
>
> About the DBJR repository:
>
> http://tinlizzie.org/dbjr/
>
> It contains ".lbox" files. Including "frank.lbox"
>
>
> About the "lbox" files:
>
> [message]
> Author: Josh Grams 
> http://vpri.org/mailman/private/fonc/2012/003089.html
>
> DBJr seems to be a Squeak thing.  Each of those .lbox directories has a
> SISS file which seems to be an S-expression serialization of Smalltalk
> objects.  Sounds like probably what you need is the stuff under "Text
> Field Spec for LObjects" on the VPRI wiki page.
>
> Not that I know *anything* about this whatsoever...
>
>
> [/message]
>
> Josh, do you mean I need the squeak VM, image and changes files?
> The active essay itself works  (except that updates break it),
>  but it doesn't seem to be an actual editor. Maybe I'm missing something.
>
> I think the lbox files are meant to be read with Lesserphic.
> According to the Lesserphic tutorial, I would need a Moshi Squeak Image.
> But I'm not sure where to get a generic, pristine one.
>
> The "Text Field Spec for LObjects" image says it is a Moshi image. Anyway,
> when I run
> the updates, it breaks. I don't know how to get out of the "Text Field"
> project
> and open a new Morphic project to try the tutorial.
> Also, I see a lot of Etoys mentions. Is it related? Maybe an Etoys image
> also works for
> Lesserphic?
>
>
>
>
> About Maru:
>
> [message]
> Author: David Girle davidgirle at gmail.com
> http://vpri.org/mailman/private/fonc/2012/003088.html
>
> Take a look at the page:
>
> http://piumarta.com/software/maru/
>
> it has the original version you have + current.
> There is a short readme in the current version with some examples that
> will get you going.
>
> [/message]
>
> This works, thanks. Maru is well worth further exploration.
> Still no GUI though ;)
>
> More to the point. So, Maru is Coke, right? I still don't get why so
> much emphasis on the fact that it can compile its own implementation
> language. Isn't that the definition of a self-hosting language,
> and isn't that feature relatively frequent these days, especially in
> Lisp-like languages? I'm just trying to understand what it's all about.
> Another doubt is that, IIRC, COLA is supposed to have two languages,
> an object language to implement computations, and a lambda language to
> describe their meaning. Does Maru fit both roles at the same time?
>
>
> [message]
> Author: Julian Leviston
> http://vpri.org/mailman/private/fonc/2012/003090.html
>
> In the tinlizzie.org/updates/exploratory/packages you'll find montecello
> packages that contains some of experiments, I'm fairly sure, one of which
> is: (yep, you guessed it)
>
> FrankVersion-yo.16.mcz
> [/message]
>
> I loaded this Monticello package from a squeak image, but nothing
> happened. It's described as "a dummy package to keep monotonic update
> numbers" or something like that. I also tried to load Gezira, but there are
> dependency issues and other errors. Maybe someone with more Squeak
> experience can clear that up. Maybe we need a Moshi Squeak image.
>
> An aside:
>
> By the way, my commentary about Jedi elitism was largely in jest. Pretty
> much all great visionaries have their qu

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Julian Leviston

Two things spring out of this at me (inline): 

On 28/02/2012, at 9:21 PM, Loup Vaillant wrote:

> - Features matter more than I think they do.
> - One may not expect the user to write his own features, even though
>   it would be relatively simple.

What about when using software becomes "writing" features - see etoys. Is 
clicking and dragging tiles still "writing" software? :)

> - Current systems may be not as badly written as I think they are.
> - Code reuse could be harder than I think.

It's not that they're written badly, it's just that that so many years on, no 
one has really understood some of the powerful ideas of yesteryear. Even those 
powerful ideas allowed a certain level of magnification... but the powerful 
ideas of these days in addition to the past allow an incredibly large 
possibility of magnification of thought... 

A good comparison would be:

- Engineer "A" understands what a lever does, therefore with that simple 
understanding can apply this knowledge to any number of concrete examples - it 
takes him almost no time to work out how to implement a lever. He teaches his 
apprentices this simple rule and law of physics, quite quickly, and they can 
write it down in a couple of sentences on a single piece of paper and also 
utilise it whenever and wherever they see fit. The Engineer "A" charges about 
$40 to implement a lever.

- Engineer "B" doesn't understand what a lever does, but he does have a 1000 
page book that illustrates almost every possible use of a lever, so when he 
finds a need, he looks up his well indexed book, which only takes a few minutes 
at the most... and then he can effectively do 90% of what Engineer "A" can do, 
but not actually understanding it, his implementations aren't as good. His 
apprentices get a copy of this book which only costs them $40 and which they 
have to familiarise themselves with. The book weighs two pounds, and they have 
to take it everywhere. The Engineer "B" charges only $50 to implement one of 
his 1000 page book ideas... he also charges $10 per minute that it takes to 
look it up.

> - The two orders of magnitude that seem to come from problem oriented
>   languages may not come from _only_ those.  It could come from the
>   removal of features, as well as better engineering principles,
>   meaning I'm counting some causes twice.
> 
> Loup.

Julian___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Martin Baldan

Guys, there are so much lines of inquiry in this thread I'm getting lost.
Here's a little summary.





[message]
Author: Julian Leviston 
http://vpri.org/mailman/private/fonc/2012/003081.html

As I understand it, Frank is an experiment that is an extended version of
DBJr that sits atop lesserphic, which sits atop gezira which sits atop
nile, which sits atop maru all of which which utilise ometa and the
"worlds" idea.

If you look at the http://vpri.org/html/writings.php page you can see a
pattern of progression that has emerged to the point where Frank exists.
>From what I understand, maru is the finalisation of what began as pepsi and
coke. Maru is a simple s-expression language, in the same way that pepsi
and coke were. In fact, it looks to have the same syntax. Nothing is the
layer underneath that is essentially a symbolic computer - sitting between
maru and the actual machine code (sort of like an LLVM assembler if I've
understood it correctly).
[..]
http://www.vpri.org/vp_wiki/index.php/Main_Page

On the bottom of that page, you'll see a link to the tinlizzie site that
references "experiment" and the URL has dbjr in it... as far as I
understand it, this is as much frank as we've been shown.

http://tinlizzie.org/dbjr/

[/message]


About the DBJR repository:

http://tinlizzie.org/dbjr/

It contains ".lbox" files. Including "frank.lbox"


About the "lbox" files:

[message]
Author: Josh Grams 
http://vpri.org/mailman/private/fonc/2012/003089.html

DBJr seems to be a Squeak thing.  Each of those .lbox directories has a
SISS file which seems to be an S-expression serialization of Smalltalk
objects.  Sounds like probably what you need is the stuff under "Text
Field Spec for LObjects" on the VPRI wiki page.

Not that I know *anything* about this whatsoever...


[/message]

Josh, do you mean I need the squeak VM, image and changes files?
The active essay itself works  (except that updates break it),
 but it doesn't seem to be an actual editor. Maybe I'm missing something.

I think the lbox files are meant to be read with Lesserphic.
According to the Lesserphic tutorial, I would need a Moshi Squeak Image.
But I'm not sure where to get a generic, pristine one.

The "Text Field Spec for LObjects" image says it is a Moshi image. Anyway,
when I run
the updates, it breaks. I don't know how to get out of the "Text Field"
project
and open a new Morphic project to try the tutorial.
Also, I see a lot of Etoys mentions. Is it related? Maybe an Etoys image
also works for
Lesserphic?




About Maru:

[message]
Author: David Girle davidgirle at gmail.com
http://vpri.org/mailman/private/fonc/2012/003088.html

Take a look at the page:

http://piumarta.com/software/maru/

it has the original version you have + current.
There is a short readme in the current version with some examples that
will get you going.

[/message]

This works, thanks. Maru is well worth further exploration.
Still no GUI though ;)

More to the point. So, Maru is Coke, right? I still don't get why so
much emphasis on the fact that it can compile its own implementation
language. Isn't that the definition of a self-hosting language,
and isn't that feature relatively frequent these days, especially in
Lisp-like languages? I'm just trying to understand what it's all about.
Another doubt is that, IIRC, COLA is supposed to have two languages,
an object language to implement computations, and a lambda language to
describe their meaning. Does Maru fit both roles at the same time?


[message]
Author: Julian Leviston
http://vpri.org/mailman/private/fonc/2012/003090.html

In the tinlizzie.org/updates/exploratory/packages you'll find montecello
packages that contains some of experiments, I'm fairly sure, one of which
is: (yep, you guessed it)

FrankVersion-yo.16.mcz
[/message]

I loaded this Monticello package from a squeak image, but nothing happened.
It's described as "a dummy package to keep monotonic update numbers" or
something like that. I also tried to load Gezira, but there are dependency
issues and other errors. Maybe someone with more Squeak experience can
clear that up. Maybe we need a Moshi Squeak image.

An aside:

By the way, my commentary about Jedi elitism was largely in jest. Pretty
much all great visionaries have their quirks and I don't mind it at all
that they prefer to focus on children. OTOH, there's a number of reasons
why I humbly think the emphasis on children may not yield the expected
benefits. The underlying assumption seems to be that people have a strong
tendency to stick to their childhood toys, so if only
those toys were based on powerful tools, a new generation of programmers
would build their adult tools from their childhood toys.

In practice, I see two problems with this idea. First, when children become
teenagers they are usually more than happy to throw their toys aways and
grab the adult stuff, to feel like adults. If there's no adult-friendly
version of the powerful technology, they will
simply use the crappy technology other

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Loup Vaillant


Originally,  the VPRI claims to be able to do a system that's 10,000
smaller than our current bloatware.  That's going from roughly 200
million lines to 20,000. (Or, as Alan Kay puts it, from a whole library
to a single book.) That's 4 orders of magnitude.

From the report, I made a rough break down of the causes for code
reduction.  It seems that

 - 1 order of magnitude is gained by removing feature creep.  I agree
   feature creep can be important.  But I also believe most feature
   belong to a long tail, where each is needed by a minority of users.
   It does matter, but if the rest of the system is small enough,
   adding the few features you need isn't so difficult any more.

 - 1 order of magnitude is gained by mere good engineering principles.
   In Frank for instance, there is _one_ drawing system, that is used
   for everywhere.  Systematic code reuse can go a long way.
 Another example is the  code I work with.  I routinely find
   portions whose volume I can divide by 2 merely by rewriting a couple
   of functions.  I fully expect to be able to do much better if I
   could refactor the whole program.  Not because I'm a rock star (I'm
   definitely not).  Very far from that.  Just because the code I
   maintain is sufficiently abysmal.

 - 2 orders of magnitude are gained through the use of Problem Oriented
   Languages (instead of C or C++). As examples, I can readily recall:
+ Gezira vs Cairo(÷95)
+ Ometa  vs Lex+Yacc (÷75)
+ TCP-IP (÷93)
   So I think this is not exaggerated.

Looked at it this way, it doesn't seems so impossible any more.  I
don't expect you to suddenly agree the "4 orders of magnitude" claim
(It still defies my intuition), but you probably disagree specifically
with one of my three points above.  Possible objections I can think of
are:

 - Features matter more than I think they do.
 - One may not expect the user to write his own features, even though
   it would be relatively simple.
 - Current systems may be not as badly written as I think they are.
 - Code reuse could be harder than I think.
 - The two orders of magnitude that seem to come from problem oriented
   languages may not come from _only_ those.  It could come from the
   removal of features, as well as better engineering principles,
   meaning I'm counting some causes twice.

Loup.


BGB wrote:

On 2/27/2012 10:08 PM, Julian Leviston wrote:

Structural optimisation is not compression. Lurk more.


probably will drop this, as arguing about all this is likely pointless
and counter-productive.

but, is there any particular reason for why similar rules and
restrictions wouldn't apply?

(I personally suspect that similar applies to nearly all forms of
communication, including written and spoken natural language, and a
claim that some X can be expressed in Y units does seem a fair amount
like a compression-style claim).


but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem


Julian

On 28/02/2012, at 3:38 PM, BGB wrote:


granted, I remain a little skeptical.

I think there is a bit of a difference though between, say, a log
table, and a typical piece of software.
a log table is, essentially, almost pure redundancy, hence why it can
be regenerated on demand.

a typical application is, instead, a big pile of logic code for a
wide range of behaviors and for dealing with a wide range of special
cases.


"executable math" could very well be functionally equivalent to a
"highly compressed" program, but note in this case that one needs to
count both the size of the "compressed" program, and also the size of
the program needed to "decompress" it (so, the size of the system
would also need to account for the compiler and runtime).

although there is a fair amount of redundancy in typical program code
(logic that is often repeated, duplicated effort between programs,
...), eliminating this redundancy would still have a bounded
reduction in total size.

increasing abstraction is likely to, again, be ultimately bounded
(and, often, abstraction differs primarily in form, rather than in
essence, from that of moving more of the system functionality into
library code).


much like with data compression, the concept commonly known as the
"Shannon limit" may well still apply (itself setting an upper limit
to how much is expressible within a given volume of code).

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-28 Thread Ryan Mitchley


On 27/02/2012 19:48, Tony Garnock-Jones wrote:


My interest in it came out of thinking about integrating pub/sub 
(multi- and broadcast) messaging into the heart of a language. What 
would a Smalltalk look like if, instead of a strict unicast model with 
multi- and broadcast constructed atop (via Observer/Observable), it 
had a messaging model capable of natively expressing unicast, anycast, 
multicast, and broadcast patterns?




I've wondered if pattern matching shouldn't be a foundation of method 
resolution (akin to binding with backtracking in Prolog) - if a 
multicast message matches, the "method" is invoked (with much less 
specificity than traditional method resolution by name/token). This is 
maybe closer to the biological model of a cell surface receptor.


Of course, complexity is an issue with this approach (potentially 
NP-complete).


Maybe this has been done and I've missed it.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

On 2/27/2012 10:08 PM, Julian Leviston wrote:

Structural optimisation is not compression. Lurk more.

probably will drop this, as arguing about all this is likely pointless
and counter-productive.

but, is there any particular reason for why similar rules and
restrictions wouldn't apply?

(I personally suspect that similar applies to nearly all forms of
communication, including written and spoken natural language, and a
claim that some X can be expressed in Y units does seem a fair amount
like a compression-style claim).

but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem

Julian

On 28/02/2012, at 3:38 PM, BGB wrote:

granted, I remain a little skeptical.

I think there is a bit of a difference though between, say, a log table, and a
typical piece of software.
a log table is, essentially, almost pure redundancy, hence why it can be
regenerated on demand.

a typical application is, instead, a big pile of logic code for a wide range of
behaviors and for dealing with a wide range of special cases.

"executable math" could very well be functionally equivalent to a "highly compressed" program, but
note in this case that one needs to count both the size of the "compressed" program, and also the size of the
program needed to "decompress" it (so, the size of the system would also need to account for the compiler and
runtime).

although there is a fair amount of redundancy in typical program code (logic
that is often repeated, duplicated effort between programs, ...), eliminating
this redundancy would still have a bounded reduction in total size.

increasing abstraction is likely to, again, be ultimately bounded (and, often,
abstraction differs primarily in form, rather than in essence, from that of
moving more of the system functionality into library code).

much like with data compression, the concept commonly known as the "Shannon
limit" may well still apply (itself setting an upper limit to how much is
expressible within a given volume of code).

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Julian Leviston

Structural optimisation is not compression. Lurk more.

Julian

On 28/02/2012, at 3:38 PM, BGB wrote:

> granted, I remain a little skeptical.
> 
> I think there is a bit of a difference though between, say, a log table, and 
> a typical piece of software.
> a log table is, essentially, almost pure redundancy, hence why it can be 
> regenerated on demand.
> 
> a typical application is, instead, a big pile of logic code for a wide range 
> of behaviors and for dealing with a wide range of special cases.
> 
> 
> "executable math" could very well be functionally equivalent to a "highly 
> compressed" program, but note in this case that one needs to count both the 
> size of the "compressed" program, and also the size of the program needed to 
> "decompress" it (so, the size of the system would also need to account for 
> the compiler and runtime).
> 
> although there is a fair amount of redundancy in typical program code (logic 
> that is often repeated,  duplicated effort between programs, ...), 
> eliminating this redundancy would still have a bounded reduction in total 
> size.
> 
> increasing abstraction is likely to, again, be ultimately bounded (and, 
> often, abstraction differs primarily in form, rather than in essence, from 
> that of moving more of the system functionality into library code).
> 
> 
> much like with data compression, the concept commonly known as the "Shannon 
> limit" may well still apply (itself setting an upper limit to how much is 
> expressible within a given volume of code).

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/27/2012 4:23 PM, Charles Perkins wrote:

Hello everyone.

I think of the code size reduction like this:

A book of logarithm tables may be hundreds of pages in length and yet the 
equation producing the numbers can fit on one line.

VPRI is exploring "runnable math" and is seeking key equations from which the 
functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced.

It's not about code compression, its about functionality expansion.


granted, I remain a little skeptical.

I think there is a bit of a difference though between, say, a log table, 
and a typical piece of software.
a log table is, essentially, almost pure redundancy, hence why it can be 
regenerated on demand.


a typical application is, instead, a big pile of logic code for a wide 
range of behaviors and for dealing with a wide range of special cases.



"executable math" could very well be functionally equivalent to a 
"highly compressed" program, but note in this case that one needs to 
count both the size of the "compressed" program, and also the size of 
the program needed to "decompress" it (so, the size of the system would 
also need to account for the compiler and runtime).


although there is a fair amount of redundancy in typical program code 
(logic that is often repeated,  duplicated effort between programs, 
...), eliminating this redundancy would still have a bounded reduction 
in total size.


increasing abstraction is likely to, again, be ultimately bounded (and, 
often, abstraction differs primarily in form, rather than in essence, 
from that of moving more of the system functionality into library code).



much like with data compression, the concept commonly known as the 
"Shannon limit" may well still apply (itself setting an upper limit to 
how much is expressible within a given volume of code).



looking it up, I found some statistics here:
http://en.wikipedia.org/wiki/Source_lines_of_code


Debian 5.0 was 324 Mloc.

Windows NT 4 was 12 Mloc.
Windows XP was 45 Mloc.

now, can a person write something like Windows XP, in, say 1/45 the 
size, and throw on top of this a reasonably complete application suite 
(browser, office apps, games, compilers for various languages, ...)?


now, can a person write an analogue of Windows XP in 1/2250 the amount 
of code?...



I have my doubts.



I also like to think of programming systems as bicycles, with levels of 
abstraction in the system as gears -- and shifting gears in todays programming 
systems is clunky. It would be nice to have a continuously variable 
transmission.


you can make things less clunky, yes, but this is not necessarily the 
same as "I can unleash full on programming magic".



it is roughly along the lines of claiming that a new transmission will 
allow one to outperform a car and travel at full highway speeds, on said 
bicycle. nevermind if said car actually burns through more total energy 
in 1 minute than a person does in 1 day.


"damn, this transmission is smooth, it is easy riding traveling 75mph on 
the freeway while pulling a trailer... on my bicycle...".




Chuck


On Feb 27, 2012, at 2:20 PM, BGB wrote:


On 2/27/2012 1:27 PM, David Girle wrote:

I am interested in the embedded uses of Maru, so I cannot comment on
"how to get from here to a Frank-like GUI".  I have no idea how many
others on this list are interested in the Internet of Things (IoT),
but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
will bring up a connected, smart sensor system, rather than the 20kLOC
target VPRI have in mind for a programming system.

David

IoT: had to look it up, but it sounds like something which could easily turn 
very cyber-punky or end up being abused in some sort of dystopic future 
scenario. accidentally touch some random object and suddenly the person has a 
price on their head and police jumping in through their window armed with 
automatic weapons or something...

and escape is difficult as doors will automatically lock on their approach, and random 
objects will fly into their path as they try to make a run for it, ... (because reality 
itself has something akin to the "Radiant AI" system from Oblivion or Fallout 
3).

(well, ok, not that I expect something like this would necessarily happen... or 
that the idea is necessarily a bad idea...).


granted, as for kloc:
code has to go somewhere, I don't think 5 kloc is going to work.

looking at the Maru stuff from earlier, I would have to check, but I suspect it 
may already go over that budget (by quickly looking at a few files and adding 
up the line counts).


admittedly, I don't as much believe in the tiny kloc goal, since as-is, getting 
a complete modern computing system down into a few Mloc would already be a bit 
of an achievement (vs, say, a 14 Mloc kernel running a 4 Mloc web browser, on a 
probably 10 Mloc GUI framework, all being compiled by a 5 Mloc C compiler, add 
another 1 Mloc if one wants a 3D engine, ...).


yes, one can make systems much smal

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Charles Perkins

Hello everyone.

I think of the code size reduction like this:

A book of logarithm tables may be hundreds of pages in length and yet the 
equation producing the numbers can fit on one line.

VPRI is exploring "runnable math" and is seeking key equations from which the 
functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced.

It's not about code compression, its about functionality expansion.

I also like to think of programming systems as bicycles, with levels of 
abstraction in the system as gears -- and shifting gears in todays programming 
systems is clunky. It would be nice to have a continuously variable 
transmission.

Chuck


On Feb 27, 2012, at 2:20 PM, BGB wrote:

> On 2/27/2012 1:27 PM, David Girle wrote:
>> I am interested in the embedded uses of Maru, so I cannot comment on
>> "how to get from here to a Frank-like GUI".  I have no idea how many
>> others on this list are interested in the Internet of Things (IoT),
>> but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
>> will bring up a connected, smart sensor system, rather than the 20kLOC
>> target VPRI have in mind for a programming system.
>> 
>> David
> 
> IoT: had to look it up, but it sounds like something which could easily turn 
> very cyber-punky or end up being abused in some sort of dystopic future 
> scenario. accidentally touch some random object and suddenly the person has a 
> price on their head and police jumping in through their window armed with 
> automatic weapons or something...
> 
> and escape is difficult as doors will automatically lock on their approach, 
> and random objects will fly into their path as they try to make a run for it, 
> ... (because reality itself has something akin to the "Radiant AI" system 
> from Oblivion or Fallout 3).
> 
> (well, ok, not that I expect something like this would necessarily happen... 
> or that the idea is necessarily a bad idea...).
> 
> 
> granted, as for kloc:
> code has to go somewhere, I don't think 5 kloc is going to work.
> 
> looking at the Maru stuff from earlier, I would have to check, but I suspect 
> it may already go over that budget (by quickly looking at a few files and 
> adding up the line counts).
> 
> 
> admittedly, I don't as much believe in the tiny kloc goal, since as-is, 
> getting a complete modern computing system down into a few Mloc would already 
> be a bit of an achievement (vs, say, a 14 Mloc kernel running a 4 Mloc web 
> browser, on a probably 10 Mloc GUI framework, all being compiled by a 5 Mloc 
> C compiler, add another 1 Mloc if one wants a 3D engine, ...).
> 
> 
> yes, one can make systems much smaller, but typically at a cost in terms of 
> functionality, like one has a small OS kernel that only run on a single 
> hardware configuration, a compiler that only supports a single target, a web 
> browser which only supports very minimal functionality, ...
> 
> absent a clearly different strategy (what the VPRI people seem to be 
> pursuing), the above outcome would not be desirable, and it is generally much 
> more desirable to have a feature-rich system, even if potentially the LOC 
> counts are far beyond the ability of any given person to understand (and if 
> the total LOC for the system, is likely, *huge*...).
> 
> very course estimates:
> a Linux installation DVD is 3.5 GB;
> assume for a moment that nearly all of this is (likely) compressed 
> program-binary code, and assuming that code tends to compress to approx 1/4 
> its original size with Deflate;
> so, probably 14GB of binary code;
> my approx 1Mloc app compiles to about 16.5 MB of DLLs;
> assuming everything else holds (and the basic assumptions are correct), this 
> would work out to ~ 849 Mloc.
> 
> (a more realistic estimate would need to find how much is program code vs 
> data files, and maybe find a better estimate of the binary-size to source-LOC 
> mapping).
> 
> 
> granted, there is probably a lot of redundancy which could likely be 
> eliminated, and if one assumes it is a layered tower strategy (a large number 
> of rings, with each layer "factoring out" most of what resides above it), 
> then likely a significant reduction would be possible.
> 
> the problem is, one is still likely to have an initially fairly large "wind 
> up time", so ultimately the resulting system, is still likely to be "pretty 
> damn large" (assuming it can do everything a modern OS does, and more, it is 
> still likely to be probably well into the Mloc range).
> 
> 
> but, I could always be wrong here...
> 
> 
>> On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan  wrote:
>>> David,
>>> 
>>> Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
>>> files. There are also ".k"  files, which I don't know how they differ from
>>> those, except that ".k" files are called with "./eval filename.k" while ".l"
>>> files are called with "./eval repl.l filename.l" where "filename" is the
>>> name of the file. Both kinds seem to be made of Maru code.
>>>

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Alan Kay

Hi Tony

I like what the BOOM/BLOOM people are doing quite a bit. Their version of 
"Datalog + Time" is definitely in accord with lots of our prejudices ...

Cheers,

Alan




>
> From: Tony Garnock-Jones 
>To: Alan Kay  
>Cc: Fundamentals of New Computing  
>Sent: Monday, February 27, 2012 1:44 PM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>
>On 27 February 2012 15:09, Alan Kay  wrote:
>
>Yes, I've seen it. As Gerry says, it is an extension of Guy Steele's thesis. 
>When I read this, I wished for a more interesting, comprehensive and 
>wider-ranging and -scaling example to help think with.
>
>For me, the moment of enlightenment was when I realized that by using a 
>lattice at each node, they'd abstracted out the essence of 
>"iterate-to-fixpoint" that's disguised within a number of the examples I 
>mentioned in my previous message. (Particularly the frameworks of abstract 
>interpretation.)
>
>I'm also really keen to try to relate propagators to Joe Hellerstein's recent 
>work on BOOM/BLOOM. That team has been able to implement the Chord DHT in 
>fewer than 50 lines of code. The underlying fact-propagation system of their 
>language integrates with a Datalog-based reasoner to permit terse, dense 
>reasoning about distributed state.
> 
>One reason to put up with some of the problems of defining things using 
>constraints is that if you can organize things well enough, you get super 
>clarity and simplicity and power.
>
>Absolutely. I think Hellerstein's Chord example shows that very well. So I 
>wish it had been an example in Radul's thesis :-)
> 
>With regard to objects, my current prejudice is that "objects should be able 
>to receive messages, but should not have to send to explicit receivers". This 
>is a kind of multi-cast I guess (but I think of it more like 
>publish/subscribe).
>>
>
>I'm nearing the point where I can write up the results of a chunk of my 
>current research. We have been using a pub/sub-based virtual machine for 
>actor-like entities, and have found a few cool uses of non-point-to-point 
>message passing that simplify implementation of complex protocols like DNS and 
>SSH.
>
>Regards,
>  Tony
>-- 
>Tony Garnock-Jones
>tonygarnockjo...@gmail.com
>http://homepages.kcbbs.gen.nz/tonyg/
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/27/2012 1:27 PM, David Girle wrote:

I am interested in the embedded uses of Maru, so I cannot comment on
"how to get from here to a Frank-like GUI".  I have no idea how many
others on this list are interested in the Internet of Things (IoT),
but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
will bring up a connected, smart sensor system, rather than the 20kLOC
target VPRI have in mind for a programming system.

David


IoT: had to look it up, but it sounds like something which could easily 
turn very cyber-punky or end up being abused in some sort of dystopic 
future scenario. accidentally touch some random object and suddenly the 
person has a price on their head and police jumping in through their 
window armed with automatic weapons or something...


and escape is difficult as doors will automatically lock on their 
approach, and random objects will fly into their path as they try to 
make a run for it, ... (because reality itself has something akin to the 
"Radiant AI" system from Oblivion or Fallout 3).


(well, ok, not that I expect something like this would necessarily 
happen... or that the idea is necessarily a bad idea...).



granted, as for kloc:
code has to go somewhere, I don't think 5 kloc is going to work.

looking at the Maru stuff from earlier, I would have to check, but I 
suspect it may already go over that budget (by quickly looking at a few 
files and adding up the line counts).



admittedly, I don't as much believe in the tiny kloc goal, since as-is, 
getting a complete modern computing system down into a few Mloc would 
already be a bit of an achievement (vs, say, a 14 Mloc kernel running a 
4 Mloc web browser, on a probably 10 Mloc GUI framework, all being 
compiled by a 5 Mloc C compiler, add another 1 Mloc if one wants a 3D 
engine, ...).



yes, one can make systems much smaller, but typically at a cost in terms 
of functionality, like one has a small OS kernel that only run on a 
single hardware configuration, a compiler that only supports a single 
target, a web browser which only supports very minimal functionality, ...


absent a clearly different strategy (what the VPRI people seem to be 
pursuing), the above outcome would not be desirable, and it is generally 
much more desirable to have a feature-rich system, even if potentially 
the LOC counts are far beyond the ability of any given person to 
understand (and if the total LOC for the system, is likely, *huge*...).


very course estimates:
a Linux installation DVD is 3.5 GB;
assume for a moment that nearly all of this is (likely) compressed 
program-binary code, and assuming that code tends to compress to approx 
1/4 its original size with Deflate;

so, probably 14GB of binary code;
my approx 1Mloc app compiles to about 16.5 MB of DLLs;
assuming everything else holds (and the basic assumptions are correct), 
this would work out to ~ 849 Mloc.


(a more realistic estimate would need to find how much is program code 
vs data files, and maybe find a better estimate of the binary-size to 
source-LOC mapping).



granted, there is probably a lot of redundancy which could likely be 
eliminated, and if one assumes it is a layered tower strategy (a large 
number of rings, with each layer "factoring out" most of what resides 
above it), then likely a significant reduction would be possible.


the problem is, one is still likely to have an initially fairly large 
"wind up time", so ultimately the resulting system, is still likely to 
be "pretty damn large" (assuming it can do everything a modern OS does, 
and more, it is still likely to be probably well into the Mloc range).



but, I could always be wrong here...



On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan  wrote:

David,

Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
files. There are also ".k"  files, which I don't know how they differ from
those, except that ".k" files are called with "./eval filename.k" while ".l"
files are called with "./eval repl.l filename.l" where "filename" is the
name of the file. Both kinds seem to be made of Maru code.

I still don't know how to go from here to a Frank-like GUI. I'm reading
other replies which seem to point that way. All tips are welcome ;)

-Martin


On Mon, Feb 27, 2012 at 3:54 AM, David Girle  wrote:

Take a look at the page:

http://piumarta.com/software/maru/

it has the original version you have + current.
There is a short readme in the current version with some examples that
will get you going.

David



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Tony Garnock-Jones

On 27 February 2012 15:09, Alan Kay  wrote:

> Yes, I've seen it. As Gerry says, it is an extension of Guy Steele's
> thesis. When I read this, I wished for a more interesting, comprehensive
> and wider-ranging and -scaling example to help think with.
>

For me, the moment of enlightenment was when I realized that by using a
lattice at each node, they'd abstracted out the essence of
"iterate-to-fixpoint" that's *disguised within* a number of the examples I
mentioned in my previous message. (Particularly the frameworks of abstract
interpretation.)

I'm also really keen to try to relate propagators to Joe Hellerstein's
recent work on BOOM/BLOOM. That team has been able to implement the Chord
DHT in fewer than 50 lines of code. The underlying fact-propagation system
of their language integrates with a Datalog-based reasoner to permit terse,
dense reasoning about distributed state.

> One reason to put up with some of the problems of defining things using
> constraints is that if you can organize things well enough, you get super
> clarity and simplicity and power.
>

Absolutely. I think Hellerstein's Chord example shows that very well. So I
wish it had been an example in Radul's thesis :-)

> With regard to objects, my current prejudice is that "objects should be
> able to receive messages, but should not have to send to explicit
> receivers". This is a kind of multi-cast I guess (but I think of it more
> like publish/subscribe).
>

I'm nearing the point where I can write up the results of a chunk of my
current research. We have been using a pub/sub-based virtual machine for
actor-like entities, and have found a few cool uses of non-point-to-point
message passing that simplify implementation of complex protocols like DNS
and SSH.

Regards,
  Tony
-- 
Tony Garnock-Jones
tonygarnockjo...@gmail.com
http://homepages.kcbbs.gen.nz/tonyg/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

s, and what are the benefits? ...). like, "here is what 
exists, what use can I make of it? how can I use it to some benefit? ...".



or such...


>
> 
> From: Julian Leviston mailto:jul...@leviston.net>>
> To: Fundamentals of New Computing mailto:fonc@vpri.org>>
> Sent: Saturday, February 25, 2012 6:48 PM
> Subject: Re: [fonc] Error trying to compile COLA
>
> As I understand it, Frank is an experiment that is an extended 
version of DBJr that sits atop lesserphic, which sits atop gezira 
which sits atop nile, which sits atop maru all of which which utilise 
ometa and the "worlds" idea.
> If you look at the http://vpri.org/html/writings.php page you can 
see a pattern of progression that has emerged to the point where Frank 
exists. From what I understand, maru is the finalisation of what began 
as pepsi and coke. Maru is a simple s-expression language, in the same 
way that pepsi and coke were. In fact, it looks to have the same 
syntax. Nothing is the layer underneath that is essentially a symbolic 
computer - sitting between maru and the actual machine code (sort of 
like an LLVM assembler if I've understood it correctly).
> They've hidden Frank in plain sight. He's a patch-together of all 
their experiments so far... which I'm sure you could do if you took 
the time to understand each of them and had the inclination. They've 
been publishing as much as they could all along. The point, though, is 
you have to understand each part. It's no good if you don't understand it.
> If you know anything about Alan & VPRI's work, you'd know that their 
focus is on getting children this stuff in front as many children as 
possible, because they have so much more ability to connect to the 
heart of a problem than adults. (Nothing to do with age - talking 
about minds, not bodies here). Adults usually get in the way with 
their "stuff" - their "knowledge" sits like a kind of a filter, 
denying them the ability to see things clearly and directly connect to 
them unless they've had special training in relaxing that filter. We 
don't know how to be simple and direct any more - not to say that it's 
impossible. We need children to teach us meta-stuff, mostly this 
direct way of experiencing and looking, and this project's main aim 
appears to be to provide them (and us, of course, but not as 
importantly) with the tools to do that. Adults will come secondarily - 
to the degree they can't embrace new stuff ;-). This is what we need 
as an entire populace - to increase our general understanding - to 
reach breakthroughs previously not thought possible, and fast. Rather 
than changing the world, they're providing the seed for children to 
change the world themselves.
> This is only as I understand it from my observation. Don't take it 
as gospel or even correct, but maybe you could use it to investigate 
the parts of frank a little more and with in-depth openness :) The 
entire project is an experiment... and that's why they're not coming 
out and saying "hey guys this is the product of our work" - it's not a 
linear building process, but an intensively creative process, and most 
of that happens within oneself before any results are seen (rather 
like boiling a kettle).

> http://www.vpri.org/vp_wiki/index.php/Main_Page
> On the bottom of that page, you'll see a link to the tinlizzie site 
that references "experiment" and the URL has dbjr in it... as far as I 
understand it, this is as much frank as we've been shown.

> http://tinlizzie.org/dbjr/
> :)
> Julian
> On 26/02/2012, at 9:41 AM, Martin Baldan wrote:
>
> Is that the case? I'm a bit confused. I've read the fascinating 
reports about Frank, and I was wondering what's the closest thing one 
can download and run right now. Could you guys please clear it up for me?

>
> Best,
>
> Martin
>
> On Sat, Feb 25, 2012 at 5:23 PM, Julian Leviston 
mailto:jul...@leviston.net>> wrote:

>
> Isn't the cola basically irrelevant now? aren't they using maru 
instead? (or rather isn't maru the renamed version of coke?)

>
> Julian
>
>
> On 26/02/2012, at 2:52 AM, Martin Baldan wrote:
>
>> Michael,
>>
>> Thanks for your reply. I'm looking into it.
>>
>> Best,
>>
>>  Martin
>> ___
>> fonc mailing list
>> fonc@vpri.org <mailto:fonc@vpri.org>
>> http://vpri.org/mailman/listinfo/fonc
>
> ___
> fonc m


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread David Girle

I am interested in the embedded uses of Maru, so I cannot comment on
"how to get from here to a Frank-like GUI".  I have no idea how many
others on this list are interested in the Internet of Things (IoT),
but I expect parts of Frank will be useful in that space.  Maybe 5kLOC
will bring up a connected, smart sensor system, rather than the 20kLOC
target VPRI have in mind for a programming system.

David

On Mon, Feb 27, 2012 at 7:01 AM, Martin Baldan  wrote:
> David,
>
> Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
> files. There are also ".k"  files, which I don't know how they differ from
> those, except that ".k" files are called with "./eval filename.k" while ".l"
> files are called with "./eval repl.l filename.l" where "filename" is the
> name of the file. Both kinds seem to be made of Maru code.
>
> I still don't know how to go from here to a Frank-like GUI. I'm reading
> other replies which seem to point that way. All tips are welcome ;)
>
> -Martin
>
>
> On Mon, Feb 27, 2012 at 3:54 AM, David Girle  wrote:
>>
>> Take a look at the page:
>>
>> http://piumarta.com/software/maru/
>>
>> it has the original version you have + current.
>> There is a short readme in the current version with some examples that
>> will get you going.
>>
>> David
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Alan Kay

Hi Tony

Yes, I've seen it. As Gerry says, it is an extension of Guy Steele's thesis. 
When I read this, I wished for a more interesting, comprehensive and 
wider-ranging and -scaling example to help think with. 


One reason to put up with some of the problems of defining things using 
constraints is that if you can organize things well enough, you get super 
clarity and simplicity and power.

They definitely need a driving example that has these traits. There is a 
certain tinge of the Turing Tarpit to this paper.

With regard to objects, my current prejudice is that "objects should be able to 
receive messages, but should not have to send to explicit receivers". This is a 
kind of multi-cast I guess (but I think of it more like publish/subscribe).


Cheers,

Alan





>
> From: Tony Garnock-Jones 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Sent: Monday, February 27, 2012 9:48 AM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>
>Hi Alan,
>
>
>On 27 February 2012 11:32, Alan Kay  wrote:
>
>[...] a better constraint system. [...] This has led us to start putting 
>constraint engines into STEPS, thinking about how to automatically organize 
>various solvers, what kinds of POLs would be nice to make constraint systems 
>with, UIs for same, and so forth.
>
>Have you looked into the "Propagators" of Radul and Sussman? For example, 
>http://dspace.mit.edu/handle/1721.1/44215. His approach is closely related to 
>dataflow, with a lattice defined at each node in the graph for integrating the 
>messages that are sent to it. He's built FRP systems, type checkers, type 
>inferencers, abstract interpretation systems and lots of other fun things in a 
>nice, simple way, out of this core construct that he's placed near the heart 
>of his language's semantics.
>
>My interest in it came out of thinking about integrating pub/sub (multi- and 
>broadcast) messaging into the heart of a language. What would a Smalltalk look 
>like if, instead of a strict unicast model with multi- and broadcast 
>constructed atop (via Observer/Observable), it had a messaging model capable 
>of natively expressing unicast, anycast, multicast, and broadcast patterns? 
>Objects would be able to collaborate on responding to requests... anycast 
>could be used to provide contextual responses to requests... concurrency would 
>be smoothly integrable... more research to be done :-)
>
>Regards,
>  Tony
>-- 
>Tony Garnock-Jones
>tonygarnockjo...@gmail.com
>http://homepages.kcbbs.gen.nz/tonyg/
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/27/2012 10:30 AM, Steve Wart wrote:

Just to zero in on one idea here



Anyway I digress... have you had a look at this file?:

http://piumarta.com/software/maru/maru-2.1/test-pepsi.l

Just read the whole thing - I found it fairly interesting :) He's
build pepsi on maru there... that's pretty fascinating, right?
Built a micro smalltalk on top of the S-expression language...
and then does a Fast Fourier Transform test using it...


my case: looked some, but not entirely sure how it works though.


See the comment at the top:
./eval repl.l test-pepsi.l
eval.c is written in C, it's pretty clean code and very cool. Then 
eval.l does the same thing in a lisp-like language.


Was playing with the Little Schemer with my son this weekend - if you 
fire up the repl, cons, car, cdr stuff all work as expected.




realized I could rip the filename off the end of the URL to get the 
directory, got the C file.


initial/quick observations:
apparently uses Boehm;
type system works a bit differently than my stuff, but seems to expose a 
vaguely similar interface (except I tend to put 'dy' on the front of 
everything here, so "dycar()", "dycdr()", "dycaddr()", and most 
predicates have names like "dyconsp()" and similar, and often I 
type-check using strings rather than an enum, ...);
the parser works a bit differently than my S-Expression parser (mine 
tend to be a bit more, if/else, and read characters typically either 
from strings or "stream objects");

ANSI codes with raw escape characters (text editor not entirely happy);
mixed tabs and spaces not leading to very good formatting;
simplistic interpreter, albeit it is not entirely clear how the built-in 
functions get dispatched;

...

a much more significant difference:
in my code, this sort of functionality is spread over many different 
areas (over several different DLLs), so one wouldn't find all of it in 
the same place.


will likely require more looking to figure out how the parser or syntax 
changing works (none of my parsers do this, most are fixed-form and 
typically shun context dependent parsing).



some of my earlier/simpler interpreters were like this though, vs newer 
ones which tend to have a longer multiple-stage translation pipeline, 
and which make use of bytecode.



Optionally check out the wikipedia article on PEGs and look at the 
COLA paper if you can find it.




PEGs, apparently I may have been using them informally already (thinking 
they were EBNF), although I haven't used them for directly driving a 
parser. typically, they have been used occasionally for describing 
elements of the syntax (in documentation and similar), at least not when 
using the lazier system of "syntax via tables of examples".


may require more looking to try to better clarify the difference between 
a PEG and EBNF...
(the only difference I saw listed was that PEGs are ordered, but I would 
have assumed that a parser based on EBNF would have been implicitly 
ordered anyways, hmm...).



Anyhow, it's all self-contained, so if you can read C code and 
understand a bit of Lisp, you can watch how the syntax morphs into 
Smalltalk. Or any other language you feel like writing a parser for.


This is fantastic stuff.



following the skim and some more looking, I think I have a better idea 
how it works.



I will infer:
top Lisp-like code defines behavior;
syntax in middle defines syntax (as comment says);
(somehow) the parser invokes the new syntax, internally converting it 
into the Lisp-like form, which is what gets executed.



so, seems interesting enough...


if so, my VM is vaguely similar, albeit without the syntax definition or 
variable parser (the parser for my script language is fixed-form and 
written in C, but does parse to a Scheme-like AST system).


the assumption would have been that if someone wanted a parser for a new 
language, they would write one, assuming the semantics mapped tolerably 
to the underlying VM (exactly matching the semantics of each language 
would be a little harder though).


theoretically, nothing would really prevent writing a parser in the 
scripting language, just I had never really considered doing so (or, for 
that matter, even supporting user-defined syntax elements in the main 
parser).



the most notable difference between my ASTs and Lisp or Scheme:
all forms are special forms, and function calls need to be made via a 
special form (this was mostly to help better detect problems);

operators were also moved to special forms, for similar reasons;
there are lots more special forms, most mapping to HLL constructs (for, 
while, break, continue, ...);

...

as-is, there are also a large-number of bytecode operations, many 
related to common special cases.


for example, a recent addition called "jmp_cond_sweq" reduces several 
instructions related to "switch" into a single operation, partly 
intended for micro-optimizing (why 3 opcodes when one only needs 1?), 
and also partly intended to be

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Tony Garnock-Jones

Hi Alan,

On 27 February 2012 11:32, Alan Kay  wrote:

> [...] a better constraint system. [...] This has led us to start putting
> constraint engines into STEPS, thinking about how to automatically organize
> various solvers, what kinds of POLs would be nice to make constraint
> systems with, UIs for same, and so forth.
>

Have you looked into the "Propagators" of Radul and Sussman? For example,
http://dspace.mit.edu/handle/1721.1/44215. His approach is closely related
to dataflow, with a lattice defined at each node in the graph for
integrating the messages that are sent to it. He's built FRP systems, type
checkers, type inferencers, abstract interpretation systems and lots of
other fun things in a nice, simple way, out of this core construct that
he's placed near the heart of his language's semantics.

My interest in it came out of thinking about integrating pub/sub (multi-
and broadcast) messaging into the heart of a language. What would a
Smalltalk look like if, instead of a strict unicast model with multi- and
broadcast constructed atop (via Observer/Observable), it had a messaging
model capable of natively expressing unicast, anycast, multicast, and
broadcast patterns? Objects would be able to collaborate on responding to
requests... anycast could be used to provide contextual responses to
requests... concurrency would be smoothly integrable... more research to be
done :-)

Regards,
  Tony
-- 
Tony Garnock-Jones
tonygarnockjo...@gmail.com
http://homepages.kcbbs.gen.nz/tonyg/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread David Harris

Alan ---

I appreciate both you explanation and what you are doing.  Of course
jealousy comes into it, because you guys appear to be having a lot of fun
mixed in with your hard work, and I would love to part of that.  I know
where I would be breaking down the doors if I was starting a masters or
doctorate.   However, I have made my choices, a long time ago, and so will
have live vicariously through your reports.  The constraint system, a la
Sketchpad, is a laudable experiment and I would love to see a
hand-constructible DBjr.  You seem to be approaching a much more
understandable and malleable system, and achieving more of the promise of
computers as imagined in the sixties and seventies, rather than what seems
to be the more mundane and opaque conglomerate that is generally the case
now.

Keep up the excellent work,
David


On Monday, February 27, 2012, Alan Kay  wrote:
> Hi Julian
> I should probably comment on this, since it seems that the STEPS reports
haven't made it clear enough.
> STEPS is a "science experiment" not an engineering project.
>
> It is not at all about making and distributing an "operating system"
etc., but about trying to investigate the tradeoffs between "problem
oriented languages" that are "highly fitted" to problem spaces vs. what it
takes to design them, learn them, make them, integrate them, add
pragmatics, etc.
> Part of the process is trying many variations in interesting (or
annoying) areas. Some of these have been rather standalone, and some have
had some integration from the start.
> As mentioned in the reports, we made Frank -- tacking together some of
the POLs that were done as satellites -- to try to get a better handle on
what an integration language might be like that is much better than the
current use of Squeak. It has been very helpful to get something that is
evocative of the whole system working in a practical enough matter to use
it (instead of PPT etc) to give talks that involve dynamic demos. We got
some good ideas from this.
>
> But this project is really about following our noses, partly via getting
interested in one facet or another (since there are really too many for
just a few people to cover all of them).
>
> For example, we've been thinking for some time that the pretty workable
DBjr system that is used for visible things - documents, UI, etc. -- should
be almost constructable by hand if we had a better constraint system. This
would be the third working DBjr made by us ...
>
> And -- this year is the 50th anniversary of Sketchpad, which has also got
us re-thinking about some favorite old topics, etc.
> This has led us to start putting constraint engines into STEPS, thinking
about how to automatically organize various solvers, what kinds of POLs
would be nice to make constraint systems with, UIs for same, and so forth.
Intellectually this is kind of interesting because there are important
overlaps between the "functions + time stamps" approach of many of our POLs
and with constraints and solvers.
> This looks very fruitful at this point!
>
> As you said at the end of your email: this is not an engineering project,
but a series of experiments.
>
> One thought we had about this list is that it might lead others to
conduct similar experiments. Just to pick one example: Reuben Thomas'
thesis "Mite" (ca 2000) has many good ideas that apply here. To quote from
the opening: "Mite is a virtual machine intended to provide fast language
and machine-neutral just-in-time translation of binary-portable object code
into high quality native code, with a formal foundation." So one
interesting project could be to try going from Nile down to a CPU via Mite.
Nile is described in OMeta, so this could be a graceful transition, etc.
> In any case, we spend most of our time trying to come up with ideas that
might be powerful for systems design and ways to implement them. We
occasionally write a paper or an NSF report. We sometimes put out code so
people can see what we are doing. But what we will put out at the end of
this period will be very different -- especially in the center -- that what
we did for the center last year.
> Cheers and best wishes,
> Alan
>
>
> ________________
> From: Julian Leviston 
> To: Fundamentals of New Computing 
> Sent: Saturday, February 25, 2012 6:48 PM
> Subject: Re: [fonc] Error trying to compile COLA
>
> As I understand it, Frank is an experiment that is an extended version of
DBJr that sits atop lesserphic, which sits atop gezira which sits atop
nile, which sits atop maru all of which which utilise ometa and the
"worlds" idea.
> If you look at the http://vpri.org/html/writings.php page you can see a
pattern of progression that has emerged to the point where Frank exists.
>From what I understand, maru is the finalisation of what began a

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Steve Wart

Just to zero in on one idea here

>
>  Anyway I digress... have you had a look at this file?:
>
>  http://piumarta.com/software/maru/maru-2.1/test-pepsi.l
>
>  Just read the whole thing - I found it fairly interesting :) He's build
> pepsi on maru there... that's pretty fascinating, right? Built a micro
> smalltalk on top of the S-expression language... and then does a Fast
> Fourier Transform test using it...
>
>   my case: looked some, but not entirely sure how it works though.
>

See the comment at the top:

./eval repl.l test-pepsi.l

eval.c is written in C, it's pretty clean code and very cool. Then eval.l
does the same thing in a lisp-like language.

Was playing with the Little Schemer with my son this weekend - if you fire
up the repl, cons, car, cdr stuff all work as expected.

Optionally check out the wikipedia article on PEGs and look at the COLA
paper if you can find it.

Anyhow, it's all self-contained, so if you can read C code and understand a
bit of Lisp, you can watch how the syntax morphs into Smalltalk. Or any
other language you feel like writing a parser for.

This is fantastic stuff.

Steve
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Alan Kay

Hi Julian

I should probably comment on this, since it seems that the STEPS reports 
haven't made it clear enough.

STEPS is a "science experiment" not an engineering project. 


It is not at all about making and distributing an "operating system" etc., but 
about trying to investigate the tradeoffs between "problem oriented languages" 
that are "highly fitted" to problem spaces vs. what it takes to design them, 
learn them, make them, integrate them, add pragmatics, etc.

Part of the process is trying many variations in interesting (or annoying) 
areas. Some of these have been rather standalone, and some have had some 
integration from the start.

As mentioned in the reports, we made Frank -- tacking together some of the POLs 
that were done as satellites -- to try to get a better handle on what an 
integration language might be like that is much better than the current use of 
Squeak. It has been very helpful to get something that is evocative of the 
whole system working in a practical enough matter to use it (instead of PPT 
etc) to give talks that involve dynamic demos. We got some good ideas from this.


But this project is really about following our noses, partly via getting 
interested in one facet or another (since there are really too many for just a 
few people to cover all of them). 


For example, we've been thinking for some time that the pretty workable DBjr 
system that is used for visible things - documents, UI, etc. -- should be 
almost constructable by hand if we had a better constraint system. This would 
be the third working DBjr made by us ...


And -- this year is the 50th anniversary of Sketchpad, which has also got us 
re-thinking about some favorite old topics, etc.

This has led us to start putting constraint engines into STEPS, thinking about 
how to automatically organize various solvers, what kinds of POLs would be nice 
to make constraint systems with, UIs for same, and so forth. Intellectually 
this is kind of interesting because there are important overlaps between the 
"functions + time stamps" approach of many of our POLs and with constraints and 
solvers.

This looks very fruitful at this point!


As you said at the end of your email: this is not an engineering project, but a 
series of experiments.


One thought we had about this list is that it might lead others to conduct 
similar experiments. Just to pick one example: Reuben Thomas' thesis "Mite" (ca 
2000) has many good ideas that apply here. To quote from the opening:"Mite is a 
virtual machine intended to provide fast language and machine-neutral 
just-in-time
translation of binary-portable object code into high quality native code, with 
a formal foundation." So one interesting project could be to try going from 
Nile down to a CPU via Mite. Nile is described in OMeta, so this could be a 
graceful transition, etc.

In any case, we spend most of our time trying to come up with ideas that might 
be powerful for systems design and ways to implement them. We occasionally 
write a paper or an NSF report. We sometimes put out code so people can see 
what we are doing. But what we will put out at the end of this period will be 
very different -- especially in the center -- that what we did for the center 
last year.

Cheers and best wishes,

Alan





>
> From: Julian Leviston 
>To: Fundamentals of New Computing  
>Sent: Saturday, February 25, 2012 6:48 PM
>Subject: Re: [fonc] Error trying to compile COLA
> 
>
>As I understand it, Frank is an experiment that is an extended version of DBJr 
>that sits atop lesserphic, which sits atop gezira which sits atop nile, which 
>sits atop maru all of which which utilise ometa and the "worlds" idea.
>
>
>If you look at the http://vpri.org/html/writings.php page you can see a 
>pattern of progression that has emerged to the point where Frank exists. From 
>what I understand, maru is the finalisation of what began as pepsi and coke. 
>Maru is a simple s-expression language, in the same way that pepsi and coke 
>were. In fact, it looks to have the same syntax. Nothing is the layer 
>underneath that is essentially a symbolic computer - sitting between maru and 
>the actual machine code (sort of like an LLVM assembler if I've understood it 
>correctly).
>
>
>They've hidden Frank in plain sight. He's a patch-together of all their 
>experiments so far... which I'm sure you could do if you took the time to 
>understand each of them and had the inclination. They've been publishing as 
>much as they could all along. The point, though, is you have to understand 
>each part. It's no good if you don't understand it.
>
>
>If you know anything about Alan & VPRI's work, you'd know that their focus is 
>on getting children this st

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Reuben Thomas

On 27 February 2012 14:01, Martin Baldan  wrote:
>
> I still don't know how to go from here to a Frank-like GUI. I'm reading
> other replies which seem to point that way. All tips are welcome ;)

And indeed, maybe any discoveries could be written up at one of the Wikis:

http://vpri.org/fonc_wiki/index.php/Main_Page
http://www.vpri.org/vp_wiki/index.php/Main_Page

? There's a lot of exciting stuff to learn about here, but the tedious
details of how to build it are not among them!

-- 
http://rrt.sc3d.org
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-27 Thread Martin Baldan

David,

Thanks for the link. Indeed, now I see how to run  "eval" with ".l" example
files. There are also ".k"  files, which I don't know how they differ from
those, except that ".k" files are called with "./eval filename.k" while
".l" files are called with "./eval repl.l filename.l" where "filename" is
the name of the file. Both kinds seem to be made of Maru code.

I still don't know how to go from here to a Frank-like GUI. I'm reading
other replies which seem to point that way. All tips are welcome ;)

-Martin

On Mon, Feb 27, 2012 at 3:54 AM, David Girle  wrote:

> Take a look at the page:
>
> http://piumarta.com/software/maru/
>
> it has the original version you have + current.
> There is a short readme in the current version with some examples that
> will get you going.
>
> David
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/26/2012 11:43 PM, Julian Leviston wrote:

Hi,

Comments line...

On 27/02/2012, at 5:33 PM, BGB wrote:



I don't think it was a prank. It's not really hidden at all. If you 
pay attention, all the components of Frank are there... like I said. 
It's obviously missing certain things like Nothing, and other 
optimisations, but for the most part, all the tech is present.


sorry for asking, but is their any sort of "dense people friendly" 
version, like maybe a description on the Wiki or something?...


like, so people can get a better idea of "what things are about and 
how they all work and fit together"?... (like, in the top-down 
description kind of way?).




I don't think this is for people who aren't prepared to roll up their 
sleeves and try things out. For a start, learn SmallTalk. It's not 
hard. Go check out squeak. There are lots of resources to learn SmallTalk.




could be.

I messed with Squeak some before, but at the time got 
confused/discouraged and gave up after a little while.







My major stumbling block at the moment is understanding OMeta fully. 
This is possibly the most amazing piece of work I've seen in a long, 
long time, and there's no easy explanation of it, and no really 
simple explanation of the syntax, either. There are the papers, and 
source code and the sandboxes, but I'm still trying to understand 
how to use it. It's kind of huge. I think perhaps I need to get a 
grounding in PEGs before I start on OMeta because there seems to be 
a lot of assumed knowledge there. Mostly I'm having trouble with the 
absolute, complete basics.


Anyway I digress... have you had a look at this file?:

http://piumarta.com/software/maru/maru-2.1/test-pepsi.l

Just read the whole thing - I found it fairly interesting :) He's 
build pepsi on maru there... that's pretty fascinating, right? Built 
a micro smalltalk on top of the S-expression language... and then 
does a Fast Fourier Transform test using it...




my case: looked some, but not entirely sure how it works though.



You could do what I've done, and read the papers and then re-read them 
and re-read them and re-read them... and research all references you 
find (the whole site is totally full of references to the entire of 
programming history). I personally think knowing LISP and SmallTalk, 
some assembler, C, Self, Javascript and other things is going to be 
incredibly helpful. Also, math is the most helpful! :)




ASM and C are fairly well known to me (I currently have a little over 1 
Mloc of C code to my name, so I can probably fairly safely say "I know 
C"...).



I used Scheme before, but eventually gave up on it, mostly due to:
problems with the Scheme community (seemed to be very fragmented and 
filled with elitism);
I generally never really could "get over" the look of S-Expression 
syntax (and also the issue that no one was happy unless the code had 
Emacs formatting, but I could never really get over Emacs either);
I much preferred C style control flow (which makes arbitrary 
continues/breaks easier), whereas changing flow through a loop in Scheme 
often meant seriously reorganizing it;

...

Scheme remains as a notable technical influence though (and exposure to 
Scheme probably had a fairly notable impact on much of my subsequent 
coding practices).



JavaScript I know acceptably, given my own scripting language is partly 
based on it.
however, I have fairly little experience using it in its original 
context: for fiddling around with web-page layouts (and never really got 
into the whole "AJAX" thing).


I messed around with Self once before, but couldn't get much 
"interesting" from it, but I found the language spec and some papers on 
the VM fairly interesting, so I scavenged a bunch of ideas from there.


the main things I remember:
graph of objects, each object being a "bag of slots", with the ability 
to delegate to any number of other objects, and the ability to handle 
cyclic delegation loops;

using a big hash-table for lookups and similar;
...

many of those ideas were incorporated into my own language/VM (with 
tweaks and extensions: such as my VM has lexical scoping, and I later 
added delegation support to the lexical environment as well, ...). (I 
chose free-form / arbitrary delegation rather than the single-delegation 
of JavaScript, due to personally finding it more useful and interesting).


I had noted, however, that my model differs in a few significant ways 
from the description of Lieberman Prototypes on the site (my "clone" 
operation directly copies objects, rather than creating a new empty 
object with copy-on-write style semantics).



the current beast looks like a mix of like a C/JS/AS mix on the surface, 
but internally may have a bit more in common than Scheme and Self than 
it does with other C-like languages (much past the syntax, and 
similarities start to fall away).


but, yet, I can't really understand SmallTalk code...


granted, math is a big weak area of mine:
apparently,

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Julian Leviston

Hi,

Comments line...

On 27/02/2012, at 5:33 PM, BGB wrote:

>> 
>> I don't think it was a prank. It's not really hidden at all. If you pay 
>> attention, all the components of Frank are there... like I said. It's 
>> obviously missing certain things like Nothing, and other optimisations, but 
>> for the most part, all the tech is present.
> 
> sorry for asking, but is their any sort of "dense people friendly" version, 
> like maybe a description on the Wiki or something?...
> 
> like, so people can get a better idea of "what things are about and how they 
> all work and fit together"?... (like, in the top-down description kind of 
> way?).
> 

I don't think this is for people who aren't prepared to roll up their sleeves 
and try things out. For a start, learn SmallTalk. It's not hard. Go check out 
squeak. There are lots of resources to learn SmallTalk.


> 
>> My major stumbling block at the moment is understanding OMeta fully. This is 
>> possibly the most amazing piece of work I've seen in a long, long time, and 
>> there's no easy explanation of it, and no really simple explanation of the 
>> syntax, either. There are the papers, and source code and the sandboxes, but 
>> I'm still trying to understand how to use it. It's kind of huge. I think 
>> perhaps I need to get a grounding in PEGs before I start on OMeta because 
>> there seems to be a lot of assumed knowledge there. Mostly I'm having 
>> trouble with the absolute, complete basics.
>> 
>> Anyway I digress... have you had a look at this file?:
>> 
>> http://piumarta.com/software/maru/maru-2.1/test-pepsi.l
>> 
>> Just read the whole thing - I found it fairly interesting :) He's build 
>> pepsi on maru there... that's pretty fascinating, right? Built a micro 
>> smalltalk on top of the S-expression language... and then does a Fast 
>> Fourier Transform test using it...
>> 
> 
> my case: looked some, but not entirely sure how it works though.
> 

You could do what I've done, and read the papers and then re-read them and 
re-read them and re-read them... and research all references you find (the 
whole site is totally full of references to the entire of programming history). 
I personally think knowing LISP and SmallTalk, some assembler, C, Self, 
Javascript and other things is going to be incredibly helpful. Also, math is 
the most helpful! :)

Julian

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/26/2012 8:23 PM, Julian Leviston wrote:
I'm afraid that I am in no way a teacher of this. I'm in no way 
professing to know what I'm talking about - I've simply given you my 
observations. Perhaps we can help each other, because I'm intensely 
interested, too... I want to understand this stuff because it is chock 
full of intensely powerful ideas.




yep, generally agreed.

I generally look for interesting or useful ideas, but admittedly have a 
harder time understanding a lot of what is going on or being talked 
about here (despite being, I think, generally being fairly knowledgeable 
about most things programming-related).


there may be a domain mismatch or something though.


admittedly, I have not generally gotten as far as being really able to 
understand Smalltalk code either, nor for that matter languages too much 
different from "vaguely C-like Procedural/OO" languages, except maybe 
ASM, which I personally found not particularly difficult to 
learn/understand or read/write, but the main drawbacks of ASM being its 
verbosity and portability issues.


granted, this may be partly a matter of familiarity or similar, since I 
encountered both C and ASM (along with BASIC) at fairly young age (and 
actually partly came to understand C originally to some degree by 
looking at the compiler's ASM output, getting a "feel" for how the 
constructs mapped to ASM operations, ...).



The elitism isn't true... I've misrepresented what I was meaning to 
say - I simply meant that people who aren't fascinated enough to 
understand won't have the drive to understand it... until it gets to a 
kind of point where enough people care to explain it to the people who 
take longer to understand... This makes sense. It's how it has always 
been. Sorry for making it sound elitist. It's not, I promise you. When 
your time is limited, though (as the VPRI guys' time is), one needs to 
focus on truly expounding it to as many people as you can, so one can 
teach more teachers first... one teaches the people who can understand 
the quickest first, and then they can propagate and so on... I hope 
this is clear.




similarly, I was not meaning to apply that children having knowledge is 
a bad thing, but sadly, it seems to run contrary to common cultural 
expectations.


granted, it is possibly the case that some aspects of culture are broken 
in some ways, namely, that children are "kept in the dark", and there is 
this notion that everyone should be some sort of unthinking and passive 
consumer. except, of course, for the content producers, which would 
generally include both the media industry (TV, movies, music, ...) as a 
whole and to a lesser extent the software industry, with a sometimes 
questionable set of "Intellectual Property" laws in an attempt to uphold 
the status quo (not that IP is necessarily bad, but it could be better).


I guess this is partly why things like FOSS exist.
but, FOSS isn't necessarily entirely perfect either.


but, yes, both giving knowledge and creating a kind of "safe haven" seem 
like reasonable goals, where one can be free to tinker around with 
things with less risk from some overzealous legal department somewhere.


also nice would be if people were less likely to accuse all of ones' 
efforts of being useless, but sadly, this probably isn't going to happen 
either.



this is not to imply that I personally necessarily have much to offer, 
as beating against a wall may make one fairly well aware of just how far 
there is left to go, as "relevance" is at times a rather difficult goal 
to reach.


admittedly, I am maybe a bit dense as well. I have never really been 
very good with "abstract" concepts (nor am I particularly "intelligent" 
in the strict sense). but, I am no one besides myself (and have no one 
besides myself to fall back on), so I have to make due (and hopefully 
try to avoid annoying people too much, and causing them to despise me, ...).


like, "the only way out is through" and similar.


I don't think it was a prank. It's not really hidden at all. If you 
pay attention, all the components of Frank are there... like I said. 
It's obviously missing certain things like Nothing, and other 
optimisations, but for the most part, all the tech is present.


sorry for asking, but is their any sort of "dense people friendly" 
version, like maybe a description on the Wiki or something?...


like, so people can get a better idea of "what things are about and how 
they all work and fit together"?... (like, in the top-down description 
kind of way?).



My major stumbling block at the moment is understanding OMeta fully. 
This is possibly the most amazing piece of work I've seen in a long, 
long time, and there's no easy explanation of it, and no really simple 
explanation of the syntax, either. There are the papers, and source 
code and the sandboxes, but I'm still trying to understand how to use 
it. It's kind of huge. I think perhaps I need to get a grounding in 
PEGs before I sta

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Julian Leviston

I'm afraid that I am in no way a teacher of this. I'm in no way professing to 
know what I'm talking about - I've simply given you my observations. Perhaps we 
can help each other, because I'm intensely interested, too... I want to 
understand this stuff because it is chock full of intensely powerful ideas.

The elitism isn't true... I've misrepresented what I was meaning to say - I 
simply meant that people who aren't fascinated enough to understand won't have 
the drive to understand it... until it gets to a kind of point where enough 
people care to explain it to the people who take longer to understand... This 
makes sense. It's how it has always been. Sorry for making it sound elitist. 
It's not, I promise you. When your time is limited, though (as the VPRI guys' 
time is), one needs to focus on truly expounding it to as many people as you 
can, so one can teach more teachers first... one teaches the people who can 
understand the quickest first, and then they can propagate and so on... I hope 
this is clear.

I don't think it was a prank. It's not really hidden at all. If you pay 
attention, all the components of Frank are there... like I said. It's obviously 
missing certain things like Nothing, and other optimisations, but for the most 
part, all the tech is present.

My major stumbling block at the moment is understanding OMeta fully. This is 
possibly the most amazing piece of work I've seen in a long, long time, and 
there's no easy explanation of it, and no really simple explanation of the 
syntax, either. There are the papers, and source code and the sandboxes, but 
I'm still trying to understand how to use it. It's kind of huge. I think 
perhaps I need to get a grounding in PEGs before I start on OMeta because there 
seems to be a lot of assumed knowledge there. Mostly I'm having trouble with 
the absolute, complete basics.

Anyway I digress... have you had a look at this file?:

http://piumarta.com/software/maru/maru-2.1/test-pepsi.l

Just read the whole thing - I found it fairly interesting :) He's build pepsi 
on maru there... that's pretty fascinating, right? Built a micro smalltalk on 
top of the S-expression language... and then does a Fast Fourier Transform test 
using it...

I'm not really sure how it relates to this, tho: 

I actually have no idea about how to run one of the experiments you're talking 
about - the mbox files... from what I've read about STEPS, though, I think the 
mbox files are Frank documents... and I think Frank is kinda DBJr... at least, 
if you go to this page and look at the bottom, pay some careful attention to 
the video that appears there demonstrating some of the patchwork doll that is 
frank (if you haven't seen it already)...

http://www.vpri.org/vp_wiki/index.php/Gezira
http://tinlizzie.org/~bert/Gezira.mp4

In the tinlizzie.org/updates/exploratory/packages you'll find montecello 
packages that contains some of experiments, I'm fairly sure, one of which is: 
(yep, you guessed it)

FrankVersion-yo.16.mcz

However, having not tried this, I'm not sure of what it may be ;-) (if I were 
you, I'd take a squizz around those packages)

You probably what the Lobjects stuff and the doc editor, I'm guessing... :-S

Fairly patchy at the best, but that's the point - it's called Frank, as in 
frankenstein's monster - as in... it's a patchy mess, but it's alive... this 
stuff is a fair way off having a full stack that operates beautifully... but 
it's a start... (it seems).

Julian

On 27/02/2012, at 12:14 PM, Martin Baldan wrote:

> Julian,
> 
> Thanks, now I have a much better picture of the overall situation, although I 
> still have a lot of reading to do. I already had read a couple of Frank 
> progress reports, and some stuff about worlds, in the publications link you 
> mention. So I thought, this sounds great, how can I try this? Then I went to 
> the wiki, and there was a section called "Fundamental new computing 
> technologies", so I said "this is the thing!".  But no, the real thing was, 
> as you said, hidden in plain sight, under the unconspicuous titles such as 
> "Other prototypes and projects related to our work" and "experiment". I 
> wonder, is that some kind of prank for the uninitiated? hehe. By the way, 
> I've played a little with Squeak, Croquet and other great projects by Alan 
> and the other wonderful Smalltalk people, so I did have a sense of their 
> focus on children. I must confess I was a bit annoyed with what seemed to me 
> like Jedi elitism (as in "He is too old. Yes, too old to begin the training. 
> ") but hey, their project, their code, their rules.
> 
> So, to get back on topic,
> 
> I've downloaded Maru, The contents are:
> 
> boot-eval.c  boot.l  emit.l  eval.l  Makefile
> 
> So, the ".l" files are  
> 
> So this is the file extension for Maru's implementation language (does it 
> have a name?).
> 
> Sure enough, the very first line of "eval.l" reads:
> 
> ;;; -*- coke -*-
> 
> This made me smile. Well, actually it was a

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Josh Grams

On 2012-02-27 02:14AM, Martin Baldan wrote:
>But what else can I do with it? Should I use it to run the examples at
>"http://tinlizzie.org/dbjr/";? All I see is files with a ".lbox" file
>extension. What are those? Apparently, there are no READMEs. Could you
>please give me an example of how to try one of those experiments?

DBJr seems to be a Squeak thing.  Each of those .lbox directories has a
SISS file which seems to be an S-expression serialization of Smalltalk
objects.  Sounds like probably what you need is the stuff under "Text
Field Spec for LObjects" on the VPRI wiki page.

Not that I know *anything* about this whatsoever...

--Josh
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread David Girle

Take a look at the page:

http://piumarta.com/software/maru/

it has the original version you have + current.
There is a short readme in the current version with some examples that
will get you going.

David

On Sun, Feb 26, 2012 at 6:14 PM, Martin Baldan  wrote:
> Julian,
>
> Thanks, now I have a much better picture of the overall situation, although
> I still have a lot of reading to do. I already had read a couple of Frank
> progress reports, and some stuff about worlds, in the publications link you
> mention. So I thought, this sounds great, how can I try this? Then I went to
> the wiki, and there was a section called "Fundamental new computing
> technologies", so I said "this is the thing!".  But no, the real thing was,
> as you said, hidden in plain sight, under the unconspicuous titles such as
> "Other prototypes and projects related to our work" and "experiment". I
> wonder, is that some kind of prank for the uninitiated? hehe. By the way,
> I've played a little with Squeak, Croquet and other great projects by Alan
> and the other wonderful Smalltalk people, so I did have a sense of their
> focus on children. I must confess I was a bit annoyed with what seemed to me
> like Jedi elitism (as in "He is too old. Yes, too old to begin the training.
> ") but hey, their project, their code, their rules.
>
> So, to get back on topic,
>
> I've downloaded Maru, The contents are:
>
> boot-eval.c  boot.l  emit.l  eval.l  Makefile
>
> So, the ".l" files are
>
> So this is the file extension for Maru's implementation language (does it
> have a name?).
>
> Sure enough, the very first line of "eval.l" reads:
>
> ;;; -*- coke -*-
>
> This made me smile. Well, actually it was a mad laughter.
>
> It compiles beautifully. Yay!
>
> Now there are some ".s" files. They look like assembler code. I thought it
> was Nothing code, but the Maru webpage explains it's just ia-32. Oh, well. I
> don't know yet where Nothing enters the picture.
>
> So, this is compiled to ".o" files and linked to build the "eval"
> executable, which can take ".l" files and make a new "eval"
>  executable, and so on. So far so good.
>
> But what else can I do with it? Should I use it to run the examples at
> "http://tinlizzie.org/dbjr/"; ? All I see is files with a ".lbox" file
> extension. What are those? Apparently, there are no READMEs. Could you
> please give me an example of how to try one of those experiments?
>
> Thanks for your tips and patience ;)
>
>
>
>
> On Sun, Feb 26, 2012 at 3:48 AM, Julian Leviston 
> wrote:
>>
>> As I understand it, Frank is an experiment that is an extended version of
>> DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile,
>> which sits atop maru all of which which utilise ometa and the "worlds" idea.
>>
>> If you look at the http://vpri.org/html/writings.php page you can see a
>> pattern of progression that has emerged to the point where Frank exists.
>> From what I understand, maru is the finalisation of what began as pepsi and
>> coke. Maru is a simple s-expression language, in the same way that pepsi and
>> coke were. In fact, it looks to have the same syntax. Nothing is the layer
>> underneath that is essentially a symbolic computer - sitting between maru
>> and the actual machine code (sort of like an LLVM assembler if I've
>> understood it correctly).
>>
>> They've hidden Frank in plain sight. He's a patch-together of all their
>> experiments so far... which I'm sure you could do if you took the time to
>> understand each of them and had the inclination. They've been publishing as
>> much as they could all along. The point, though, is you have to understand
>> each part. It's no good if you don't understand it.
>>
>> If you know anything about Alan & VPRI's work, you'd know that their focus
>> is on getting children this stuff in front as many children as possible,
>> because they have so much more ability to connect to the heart of a problem
>> than adults. (Nothing to do with age - talking about minds, not bodies
>> here). Adults usually get in the way with their "stuff" - their "knowledge"
>> sits like a kind of a filter, denying them the ability to see things clearly
>> and directly connect to them unless they've had special training in relaxing
>> that filter. We don't know how to be simple and direct any more - not to say
>> that it's impossible. We need children to teach us meta-stuff, mostly this
>> direct way of experiencing and looking, and this project's main aim appears
>> to be to provide them (and us, of course, but not as importantly) with the
>> tools to do that. Adults will come secondarily - to the degree they can't
>> embrace new stuff ;-). This is what we need as an entire populace - to
>> increase our general understanding - to reach breakthroughs previously not
>> thought possible, and fast. Rather than changing the world, they're
>> providing the seed for children to change the world themselves.
>>
>> This is only as I understand it from my observation. Don't t

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Martin Baldan

Julian,

Thanks, now I have a much better picture of the overall situation, although
I still have a lot of reading to do. I already had read a couple of Frank
progress reports, and some stuff about worlds, in the publications link you
mention. So I thought, this sounds great, how can I try this? Then I went
to the wiki, and there was a section called "Fundamental new computing
technologies", so I said "this is the thing!".  But no, the real thing was,
as you said, hidden in plain sight, under the unconspicuous titles such as
"Other prototypes and projects related to our work" and "experiment". I
wonder, is that some kind of prank for the uninitiated? hehe. By the way,
I've played a little with Squeak, Croquet and other great projects by Alan
and the other wonderful Smalltalk people, so I did have a sense of their
focus on children. I must confess I was a bit annoyed with what seemed to
me like Jedi elitism (as in "He is too old. Yes, too old to begin the
training. ") but hey, their project, their code, their rules.

So, to get back on topic,

I've downloaded Maru, The contents are:

boot-eval.c  boot.l  emit.l  eval.l  Makefile

So, the ".l" files are

So this is the file extension for Maru's implementation language (does it
have a name?).

Sure enough, the very first line of "eval.l" reads:

;;; -*- coke -*-

This made me smile. Well, actually it was a mad laughter.

It compiles beautifully. Yay!

Now there are some ".s" files. They look like assembler code. I thought it
was Nothing code, but the Maru webpage explains it's just ia-32. Oh, well.
I don't know yet where Nothing enters the picture.

So, this is compiled to ".o" files and linked to build the "eval"
executable, which can take ".l" files and make a new "eval"
 executable, and so on. So far so good.

But what else can I do with it? Should I use it to run the examples at "
http://tinlizzie.org/dbjr/"; ? All I see is files with a ".lbox" file
extension. What are those? Apparently, there are no READMEs. Could you
please give me an example of how to try one of those experiments?

Thanks for your tips and patience ;)

On Sun, Feb 26, 2012 at 3:48 AM, Julian Leviston wrote:

> As I understand it, Frank is an experiment that is an extended version of
> DBJr that sits atop lesserphic, which sits atop gezira which sits atop
> nile, which sits atop maru all of which which utilise ometa and the
> "worlds" idea.
>
> If you look at the http://vpri.org/html/writings.php page you can see a
> pattern of progression that has emerged to the point where Frank exists.
> From what I understand, maru is the finalisation of what began as pepsi and
> coke. Maru is a simple s-expression language, in the same way that pepsi
> and coke were. In fact, it looks to have the same syntax. Nothing is the
> layer underneath that is essentially a symbolic computer - sitting between
> maru and the actual machine code (sort of like an LLVM assembler if I've
> understood it correctly).
>
> They've hidden Frank in plain sight. He's a patch-together of all their
> experiments so far... which I'm sure you could do if you took the time to
> understand each of them and had the inclination. They've been publishing as
> much as they could all along. The point, though, is you have to understand
> each part. It's no good if you don't understand it.
>
> If you know anything about Alan & VPRI's work, you'd know that their focus
> is on getting children this stuff in front as many children as possible,
> because they have so much more ability to connect to the heart of a problem
> than adults. (Nothing to do with age - talking about minds, not bodies
> here). Adults usually get in the way with their "stuff" - their "knowledge"
> sits like a kind of a filter, denying them the ability to see things
> clearly and directly connect to them unless they've had special training in
> relaxing that filter. We don't know how to be simple and direct any more -
> not to say that it's impossible. We need children to teach us meta-stuff,
> mostly this direct way of experiencing and looking, and this project's main
> aim appears to be to provide them (and us, of course, but not as
> importantly) with the tools to do that. Adults will come secondarily - to
> the degree they can't embrace new stuff ;-). This is what we need as an
> entire populace - to increase our general understanding - to reach
> breakthroughs previously not thought possible, and fast. Rather than
> changing the world, they're providing the seed for children to change the
> world themselves.
>
> This is only as I understand it from my observation. Don't take it as
> gospel or even correct, but maybe you could use it to investigate the parts
> of frank a little more and with in-depth openness :) The entire project is
> an experiment... and that's why they're not coming out and saying "hey guys
> this is the product of our work" - it's not a linear building process, but
> an intensively creative process, and most of that happens within onesel

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Martin Baldan

Guys, I find these off_topic comments (as in not strictly about my idst
compilation  problem)  really interesting. Maybe I should start a new
thread? Something like «how can a newbie start playing with this
technology?». Thanks!
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA


On 2/26/2012 3:53 AM, Julian Leviston wrote:
What does any of what you just said have to do with the original 
question about COLA?




sorry, I am really not good with topic, was just trying to respond to 
what was there, but it was 2AM...

(hmm, maybe I should have waited until morning? oh well...).

as for getting COLA to compile, I have little idea, hence why I did not 
comment on this.
it seemed to be going off in the direction of motivations, ... which I 
can comment on.


likewise, I can comment on Prototype OO and S-Expressions, since I have 
a lot more experience using these, ... (both, just so happen, are things 
that seem to be seen very negatively by average programmers, vs say 
Class/Instance and XML, ...). however, both continue to be useful, so 
they don't just go away (like, Lists/S-Exps are easier to work with than 
XML via DOM or similar, ...).



but, yes, maybe I will go back into lurk mode now...


Julian

On 26/02/2012, at 9:25 PM, BGB wrote:


On 2/25/2012 7:48 PM, Julian Leviston wrote:
As I understand it, Frank is an experiment that is an extended 
version of DBJr that sits atop lesserphic, which sits atop gezira 
which sits atop nile, which sits atop maru all of which which 
utilise ometa and the "worlds" idea.


If you look at the http://vpri.org/html/writings.php page you can 
see a pattern of progression that has emerged to the point where 
Frank exists. From what I understand, maru is the finalisation of 
what began as pepsi and coke. Maru is a simple s-expression 
language, in the same way that pepsi and coke were. In fact, it 
looks to have the same syntax. Nothing is the layer underneath that 
is essentially a symbolic computer - sitting between maru and the 
actual machine code (sort of like an LLVM assembler if I've 
understood it correctly).




yes, S-Expressions can be nifty.
often, they aren't really something one advertises, or uses as a 
front-end syntax (much like Prototype-OO and delegation: it is a 
powerful model, but people also like their classes).


so, one ends up building something with a C-like syntax and 
Class/Instance OO, even if much of the structure internally is built 
using lists and Prototype-OO. if something is too strange, it may not 
be received well though (like people may see it and be like "just 
what the hell is this?"). better then if everything is "just as could 
be expected".



in my case, they are often printed out in debugging messages though, 
as a lot of my stuff internally is built using lists (I ended up 
recently devising a specialized network protocol for, among other 
things, sending compressed list-based messages over a TCP socket).


probably not wanting to go too deeply into it, but:
it directly serializes/parses the lists from a bitstream;
a vaguely JPEG-like escape-tag system is used;
messages are Huffman-coded, and make use of both a value MRU/MTF and 
LZ77 compression (many parts of the coding also borrow from Deflate);
currently, I am (in my uses) getting ~60% additional compression vs 
S-Expressions+Deflate, and approximately 97% compression vs plaintext 
(plain Deflate got around 90% for this data).


the above was mostly used for sending scene-graph updates and similar 
in my 3D engine, and is maybe overkill, but whatever (although, 
luckily, it means I can send a lot more data while staying within a 
reasonable bandwidth budget, as my target was 96-128 kbps, and I am 
currently using around 8 kbps, vs closer to the 300-400 kbps needed 
for plaintext).



They've hidden Frank in plain sight. He's a patch-together of all 
their experiments so far... which I'm sure you could do if you took 
the time to understand each of them and had the inclination. They've 
been publishing as much as they could all along. The point, though, 
is you have to understand each part. It's no good if you don't 
understand it.




possibly, I don't understand a lot of it, but I guess part of it may 
be knowing what to read.
there were a few nifty things to read here and there, but I wasn't 
really seeing the larger whole I guess.



If you know anything about Alan & VPRI's work, you'd know that their 
focus is on getting children this stuff in front as many children as 
possible, because they have so much more ability to connect to the 
heart of a problem than adults. (Nothing to do with age - talking 
about minds, not bodies here). Adults usually get in the way with 
their "stuff" - their "knowledge" sits like a kind of a filter, 
denying them the ability to see things clearly and directly connect 
to them unless they've had special training in relaxing that filter. 
We don't know how to be simple and direct any more - not to say that 
it's impossible. We need children to teach us meta-stuff, mostly 
this direct way of experiencing and looking, and this project's main 
aim appears to be to provide them (and us, of course, but not as 
importantly) with the tools to do that. Adults will come secondarily 
- to the degree they can't embrace new

Re: [fonc] Error trying to compile COLA

2012-02-26 Thread Julian Leviston

What does any of what you just said have to do with the original question about 
COLA?

Julian

On 26/02/2012, at 9:25 PM, BGB wrote:

> On 2/25/2012 7:48 PM, Julian Leviston wrote:
>> 
>> As I understand it, Frank is an experiment that is an extended version of 
>> DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, 
>> which sits atop maru all of which which utilise ometa and the "worlds" idea.
>> 
>> If you look at the http://vpri.org/html/writings.php page you can see a 
>> pattern of progression that has emerged to the point where Frank exists. 
>> From what I understand, maru is the finalisation of what began as pepsi and 
>> coke. Maru is a simple s-expression language, in the same way that pepsi and 
>> coke were. In fact, it looks to have the same syntax. Nothing is the layer 
>> underneath that is essentially a symbolic computer - sitting between maru 
>> and the actual machine code (sort of like an LLVM assembler if I've 
>> understood it correctly).
>> 
> 
> yes, S-Expressions can be nifty.
> often, they aren't really something one advertises, or uses as a front-end 
> syntax (much like Prototype-OO and delegation: it is a powerful model, but 
> people also like their classes).
> 
> so, one ends up building something with a C-like syntax and Class/Instance 
> OO, even if much of the structure internally is built using lists and 
> Prototype-OO. if something is too strange, it may not be received well though 
> (like people may see it and be like "just what the hell is this?"). better 
> then if everything is "just as could be expected".
> 
> 
> in my case, they are often printed out in debugging messages though, as a lot 
> of my stuff internally is built using lists (I ended up recently devising a 
> specialized network protocol for, among other things, sending compressed 
> list-based messages over a TCP socket).
> 
> probably not wanting to go too deeply into it, but:
> it directly serializes/parses the lists from a bitstream;
> a vaguely JPEG-like escape-tag system is used;
> messages are Huffman-coded, and make use of both a value MRU/MTF and LZ77 
> compression (many parts of the coding also borrow from Deflate);
> currently, I am (in my uses) getting ~60% additional compression vs 
> S-Expressions+Deflate, and approximately 97% compression vs plaintext (plain 
> Deflate got around 90% for this data).
> 
> the above was mostly used for sending scene-graph updates and similar in my 
> 3D engine, and is maybe overkill, but whatever (although, luckily, it means I 
> can send a lot more data while staying within a reasonable bandwidth budget, 
> as my target was 96-128 kbps, and I am currently using around 8 kbps, vs 
> closer to the 300-400 kbps needed for plaintext).
> 
> 
>> They've hidden Frank in plain sight. He's a patch-together of all their 
>> experiments so far... which I'm sure you could do if you took the time to 
>> understand each of them and had the inclination. They've been publishing as 
>> much as they could all along. The point, though, is you have to understand 
>> each part. It's no good if you don't understand it.
>> 
> 
> possibly, I don't understand a lot of it, but I guess part of it may be 
> knowing what to read.
> there were a few nifty things to read here and there, but I wasn't really 
> seeing the larger whole I guess.
> 
> 
>> If you know anything about Alan & VPRI's work, you'd know that their focus 
>> is on getting children this stuff in front as many children as possible, 
>> because they have so much more ability to connect to the heart of a problem 
>> than adults. (Nothing to do with age - talking about minds, not bodies 
>> here). Adults usually get in the way with their "stuff" - their "knowledge" 
>> sits like a kind of a filter, denying them the ability to see things clearly 
>> and directly connect to them unless they've had special training in relaxing 
>> that filter. We don't know how to be simple and direct any more - not to say 
>> that it's impossible. We need children to teach us meta-stuff, mostly this 
>> direct way of experiencing and looking, and this project's main aim appears 
>> to be to provide them (and us, of course, but not as importantly) with the 
>> tools to do that. Adults will come secondarily - to the degree they can't 
>> embrace new stuff ;-). This is what we need as an entire populace - to 
>> increase our general understanding - to reach breakthroughs previously not 
>> thought possible, and fast. Rather than changing the world, they're 
>> providing the seed for children to change the world themselves.
> 
> there are merits and drawbacks here.
> 
> (what follows here is merely my opinion at the moment, as stated at a time 
> when I am somewhat in need of going to sleep... ).
> 
> 
> granted, yes, children learning stuff is probably good, but the risk is also 
> that children (unlike adults) are much more likely to play things much more 
> "fast and loose" regarding the law, and might show little

Re: [fonc] Error trying to compile COLA