[Oberon] [EXT] Re: Portable Project Oberon on GitHub

[Skulski, Wojciech]

Michael:

  thank you! I made a release with the BlackBox files according to your advice. I tried to change readme.md. Editing this file is provided, but saving the edited version is not provided without making a new branch. So I did not save the edited file. Github can be entertaining.  

In any case, there are both versions of the Oberon System files, one in the BB format and the other plain ASCII. I created the ASCII files by "save as .txt", so there are no differences other than formatting. I treat the BB versions as master files and the ASCII files as derivatives. 

I now recall that these files are not original NW files, but rather Andreas' Extended Oberon files from around Feb/2020. I think that NW Oberon is now frozen and we should rather follow Andreas' which is actively developed. This is how I sense the situation.

Let me stress that porting Oberon without cleanup will be very inefficient, ineffective, and flaky. I was quite shocked that I had to undertake such an effort after I looked at the low level source. The code was quite terrifying from the porting point of view.  

Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Michael Schierl [schierlm at gmx.de]
Sent: Monday, December 7, 2020 4:39 PM
To: oberon at lists.inf.ethz.ch
Subject: [EXT] Re: [Oberon] Portable Project Oberon on GitHub

Hello Wojtek,


Am 07.12.2020 um 22:03 schrieb Skulski, Wojciech:
> Hello:
>
>    a while ago I put the Oberon System sources under the name Portable Oberon System.
> There are two "branches" on that website. One is BlackBox format. It really should have been the native Text format, but I did the cleanup under BlackBox.
> The other "branch" contains ASCII versions of the same files. Honestly these should not be used. Meaningful cleanup requires better formatting tools than plain ASCII.


GitHub thinks there are three:

master
   Default branch
   Updated 10 months ago by WojtekSkulski

Source-files-in-BlackBox-format
   Updated 10 months ago by WojtekSkulski

Source-files-in-ASCII-format
   Updated 10 months ago by WojtekSkulski

The master branch contains only a README, and the two other branches
contain the "other" files.


> Unfortunately, I have no idea how to make these files visible to the world.

On https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_WojtekSkulski_Portable-5FOberon-5FSystem_branches&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=owr0RLdC_fOB9PIYd_vE6THDziN8958y-DP26b9-7Gg&s=sM2y05GcAIRBIeh4jubvCdr5XqFa4TTwKLbyfhpSgzU&e=
click "change default branch" and switch it over to
"Source-files-in-BlackBox-format".

People who are interested in other branches will find those in the
Branches dropdown, but the only branch that is prominently presented on
the landing page is the default branch.

Optionally delete the "master" branch then.

> I looked at "pull requests", "actions", "packages", and all the other crap which Github is pouring on my head,

"Pull Requests" are used to communicate changes that you made to a
project that you do not own. So e.g. if I fixed a bug in your code, I
could make a pull request that you could review and integrate. Sometimes
they are also used in projects with multiple developers for one
developer to request review of his changes by another one. So far I have
not found any good reason why to create a pull request on a GitHub
repository that you own and where you are the only contributor.

"Actions" is what others would call continuous integration / continuous
testing. There you can add (Unix shell) scripts that are run
automatically whenever someone commits code, or whenever somebody
creates a pull request. Those scripts could for example try to build the
project and create an error if there is a compile time error caused by
the change. Or the scripts could automatically convert files of exotic
binary file types into HTML (if such converters exist) or even plain
text, so that they can be more easily viewed/reviewed on the Web.

"Packages" are some newfangled stuff that Oberon purists probably would
not want to use. Basically, they are a way to publish things to certain
ecosystems (NPM for JavaScript modules, Maven for Java modules, etc.) so
that they can be added as a library from some integrated development
tools or editors. (So I just say I want to use "junit:junit" and Maven
will take care to download the latest library for me and add it to my
project). Packages are nothing invented by GitHub, they just provide
convenience functions for popular package managers so you don't have to
deal with them individually.


> and I have not found an answer to a simple question "how to make the files public". Can someone more knowledgeable than I go there and just release this stuff so anybody can see it? Alternatively, please tell me how I can do it.

I could try sending a pull request to pull everything in your branch
into the master branch. But I guess it is harder for you to accept this
(and still you would then have 2 identical branches) than just cleaning
up your branches :-)

> I just read how to make a release, followed the procedure, and the only file which was released was the readme.

You probably based the release off the master branch, which only
contains the readme.



Regards,


Michael
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=owr0RLdC_fOB9PIYd_vE6THDziN8958y-DP26b9-7Gg&s=ujzLit69QZV46A1O-0g0Ya2FcrwhtdfFNMjEiX7hzy0&e=