[Oberon] [EXT] Re: all in one git tree

[Jörg]

There are two totally different usages of Oberon:
1) use the Oberon language WITHOUT the Oberon OS. Here the Oberon language is used as a replacement for another programming language. The source files are pure ASCII files, as in most cases the IDE to build native apps can not understand more than this. Git can be used easily. Ofront is a project that uses this kind of Oberon.

2) use the Oberon language WITH the Oberon OS. The Oberon OS does not offer ASCII files but offers as base type a Text file enhanced with fonts, colors and depending on the version of the Oberon OS, version control, folding mechanisms, animated graphics and a lot more. As analogy you might compare these text files with Word documents, offering a lot of extra info in addition to the Human readable characters. 
Out-of-the-box, the Oberon OS is able to read ASCII files, but writing ASCII files needs a special „export“ procedure, typically called EditToos.StoreAscii or ET.StoreAscii. BTW: „pure ASCII files“ are OS dependent because of the fifferent newline characters used by the differnt OSes.
As git does not understand this text format, comparing versions is almost impossible, especially if you use version elements in your source. (version elements are comparable to the preprocessor directive #IF)

br, Jörg

> Am 25.12.2020 um 20:36 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Chuck:
> 
>> I think we are missing a tool in Oberon that would enable coordinated development without prescribing a central authority. 
> 
> A "coordinated development without central authority" is a misnomer. The coordinator becomes an authority by definition. The gist of my yesterday message was that this community is unlikely to accept the coordinator, if it has not done so for the last 20+ years. 
> 
> Git or other version control tools cater to the needs of other communities. Forcing such tools in this community is impossible. Voluntary adoption has partly happened. Any "key person" who wanted to have the repository, already has one. Merging them into a single repository is unlikely, because the "cardinals" (as Andreas has said) would need to decide who is the pope. This can happen, but only voluntarily. If it happens, then the pope will make the arrangements. Lacking the pope, one central repository is unlikely to be founded.
> 
> Note that the "most equal among equals" also has his repository, which is not even in git. It is just a collection of ASCII files on a single web page. It is playing a central role in this community at least declaratively. But the "most equal among equals" has refused to govern.
> 
> This is the way it is. Git is not going to change what the key persons want to achieve and how they are doing it.
> 
>> A source-code packaging system could fill this need.  
> 
> I looked at your proposition and I can see an immediate problem. It assumes ASCII format either implicitly or explicitly. Here is a citation: 
> 
> "conversion (LF <--> CRLF) for distributions keeping Original Project Oberon text format". It is implying that the only difficulty is the line endings. But this is far from present reality.
> 
> It is true that the original Oberon System was based on plain text with only minor additions like font, its size, and style.  Stripping the original Oberon Text from the font information is not doing extensive damage to the original System, because these "embellishments" were frosting on the cake. The original Oberon System without the fonts will look even more dull than the original, but it will still function. So the key programmers feel inclined to do so. Most programmers seem to think that the Courier font is the only font that should ever exist. Stripping all the font info and putting the ASCII files on the web looks like a good path to an even simpler System. Let's do it, right?
> 
> Not right. The original was 30 years ago. Oberon System has traveled a long way from the original. Fonts, styles, and colors might have been just niceties. But then Clemens Szyperski made a decisive step forward with his thesis. Oberon Text format has become more than a text (despite the name). It became a framework for "Writing the applications". The Elements are not just genial. They became the tools for developing non trivial functionality. The Oberon Walking Man is just a toy. But the data displays embedded inside the Write documents are not toys. They are essential. Without them the Oberon System has much less relevance.
> 
> Then the next competitive step was made by Gutknecht and his group. Gadgets are Elements on steroids and the whole System 3 is a one huge GUI which goes miles beyond Text.
> 
> None of this is possible to render in the stripped ASCII modules. All these panels, elements, text formatting, Kepler graphs, etc, etc - are integral parts of various revisions of the Oberon System. Without handling these we will be going back by 30 years. There is no point in doing this.
> 
>> What we need is an Oberon-centric source-code package management system that allows for the completely independent development that is typical of Oberon coders.
> 
> Code is not sufficient because the Oberon System is not only code. I mean, the modern one. The original, yes. The 2013 reenactment, yes. But any later revisions, like V4 or System 3, are not.
> 
>> In the spirit of Oberon the packages descriptions are as simple as possible, just csv text files. 
> 
> There is really no point in doing so. NW has turned back 30 years with his 2013 edition. He did this for preservation rather than for development. His 2013 edition was cut down to the bone. No Write, no Elements, no panels, no nothing. All the great tools were stripped off due to lack of RAM. I can understand this. But staying there? No.
> 
> Wojtek
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon