4 ms·

Vishap Oberon Compiler

29 points by sevoves 2y ago

pjmlp 2y ago
Oberon-2 was my entry point into the Oberon ecosystem, the world of systems programming with automatic resource management languages, and all the cool ideas that are routinely explored on that parallel computing universe where the whole OS stack is mostly safe. Unfortunely moving past UNIX clones and C seems a task only to be fulfiled by the true hero that is yet to come as per the old prophecy, routinely told by village elders on cold Winter nights around a warm fireplace to keep children entertained.
- lproven 2y ago
  Absolutely. In the meantime they are busy making more elaborate versions of C. «C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable".» https://x.com/smdiehl/status/855827759872045056 https://x.com/smdiehl/status/855827759872045056
  - Rochus 2y ago
    > In the meantime they are busy making more elaborate versions of C. Or better C versions which look like Oberon: https://github.com/micron-language/specification https://github.com/micron-language/specification
    - lproven 2y ago
      :-D Nice work...
vdupras 2y ago
Compiling Oberon to native code, nice! Since Oberon is as much a compiler as it's a complete system, a big part of the work is to integrate that system into its host. It seems they've done it for files and stdin/stdout, but not for the graphical system yet (through SDL or something). I wonder if it's on their roadmap. As a shameless plug, I'm in the process of doing something very similar[1] for Dusk OS[2]. [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/comp/oberon.txt https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co... [2]: http://duskos.org http://duskos.org
- Rochus 2y ago
  > Since Oberon is as much a compiler as it's a complete system, The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/ https://github.com/rochus-keller/OberonSystem3/.
- sevoves 2y ago
  Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g. PROCEDURE -fstat(fd: LONGINT): INTEGER "fstat(fd, &s)"; Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards. [1]:https://github.com/vishapoberon/compiler/tree/master/src/library/oocX11 https://github.com/vishapoberon/compiler/tree/master/src/lib... [2]:https://github.com/norayr/http/ https://github.com/norayr/http/ [3]:https://github.com/vishapoberon/vipack https://github.com/vishapoberon/vipack > very similar[1] for Dusk OS[2] wow this is cool
- joshu 2y ago
  I love what you’re doing with duskos! have been watching for a while.
  - vdupras 2y ago
    Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional. But this stuff (well, Forth in general) requires such a big shift in mindset as to how we approach computing that I understand why it stays niche. Kind of like Lisp but, IMO, deeper.

29 points by sevoves 2y ago

Oberon-2 was my entry point into the Oberon ecosystem, the world of systems programming with automatic resource management languages, and all the cool ideas that are routinely explored on that parallel computing universe where the whole OS stack is mostly safe. Unfortunely moving past UNIX clones and C seems a task only to be fulfiled by the true hero that is yet to come as per the old prophecy, routinely told by village elders on cold Winter nights around a warm fireplace to keep children entertained.

lproven 2y ago
Absolutely. In the meantime they are busy making more elaborate versions of C. «C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable".» https://x.com/smdiehl/status/855827759872045056 https://x.com/smdiehl/status/855827759872045056
- Rochus 2y ago
  > In the meantime they are busy making more elaborate versions of C. Or better C versions which look like Oberon: https://github.com/micron-language/specification https://github.com/micron-language/specification
  - lproven 2y ago
    :-D Nice work...

vdupras 2y ago

Compiling Oberon to native code, nice! Since Oberon is as much a compiler as it's a complete system, a big part of the work is to integrate that system into its host. It seems they've done it for files and stdin/stdout, but not for the graphical system yet (through SDL or something). I wonder if it's on their roadmap. As a shameless plug, I'm in the process of doing something very similar[1] for Dusk OS[2]. [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/comp/oberon.txt https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co... [2]: http://duskos.org http://duskos.org

Rochus 2y ago
> Since Oberon is as much a compiler as it's a complete system, The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/ https://github.com/rochus-keller/OberonSystem3/.
sevoves 2y ago
Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g. PROCEDURE -fstat(fd: LONGINT): INTEGER "fstat(fd, &s)"; Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards. [1]:https://github.com/vishapoberon/compiler/tree/master/src/library/oocX11 https://github.com/vishapoberon/compiler/tree/master/src/lib... [2]:https://github.com/norayr/http/ https://github.com/norayr/http/ [3]:https://github.com/vishapoberon/vipack https://github.com/vishapoberon/vipack > very similar[1] for Dusk OS[2] wow this is cool
joshu 2y ago
I love what you’re doing with duskos! have been watching for a while.
- vdupras 2y ago
  Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional. But this stuff (well, Forth in general) requires such a big shift in mindset as to how we approach computing that I understand why it stays niche. Kind of like Lisp but, IMO, deeper.