3 ms·

Just tried with my Oberon+ IDE and get a Hello.dll of 2048 bytes for this module: module Hello begin println("hello world") end Hello It uses the ht

by Rochus 3y ago

Just tried with my Oberon+ IDE and get a Hello.dll of 2048 bytes for this module: module Hello begin println("hello world") end Hello It uses the https://github.com/rochus-keller/Pelib https://github.com/rochus-keller/Pelib assembly generator.

cyptus 3y ago
is the file filled with 0 bytes at the end? I think there are options to disable this
- Rochus 3y ago
  Yes, it has about 700 zero bytes at the end; might be just some overhead due to the PE format; didn't have a close look, was just curious how big it is out of the box after skimming the article. Anyway the size of the DLL itself is irrelevant compared to the binaries required to run it (Mono + mscorlib.dll ~ 10 MB in case of Oberon+).
analognoise 3y ago
Nicklaus Wirth was right. I felt that the first time I used Lazarus/FreePascal, and felt it to be true the more of his works I read. Recently though, I think maybe the way to get off the "cycle of reincarnation" for this type of thinking is to do WASM - but I cannot abandon hardware like that. I am mentally incapable of accepting a spiritual machine that I cannot break with a hammer upon my desk; [I am] too primitive; an indestructible global computer that runs on other people's hardware for thousands of dollars of compute time and is slower than an RPi (like Ethereum) is anathema to me in some fundamental way. I still want to get that (Wirth was right) on a shirt with his face on it.
- Rochus 3y ago
  > Nicklaus Wirth was right In what respect in this context? I should have explicitly stated that "Hello.dll" is a .NET assembly, i.e. Oberon+ uses the Mono CLR to run and debug the Oberon+ code (but not the .NET framework); it can also generate C99 (as a substitute for AOT compilation), but here it is about the minimal size of a Hello World .NET binary. WASM and especially the WAMR runtime might be a good alternative to the Mono CLR in future, but today it's too slow and only a few architectures are supported (much less than Mono).
cxr 3y ago
> It uses the https://github.com/rochus-keller/Pelib https://github.com/rochus-keller/Pelib assembly generator. Shouldn't Oberon+ be self-hosting? There's so much C++ ecosystem crud. It reminds me of all those projects for open source software hosting forges promoted as alternatives to GitHub and Gitlab, and then when you go to clone their code or file a bug... it's all on GitHub...
- Rochus 3y ago
  C++, in the moderate subset e.g. also used in Qt 1 to 5, I still consider to be the optimal implementation language for a compiler and IDE at the present state of Oberon+ development, not because C++ is such a great language, but because of the ubiquitous availability and the huge, proven code base, which allows me to implement a project like Oberon+ as a single person worlds faster and more robust than with any other technology I know. As an illustrative example of this efficiency, I would like to cite https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPascal, where I was able to implement a parser and code browser within a week as a side project. With any other technology (including Smalltalk or Delphi) this would have taken months. A lot of development is still needed for Oberon+ to reach this point, and using the present approach I can support this development with sufficiently powerful tools.
  - cxr 3y ago
    > As an illustrative example of this efficiency, I would like to cite https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPascal, where I was able to implement a parser and code browser within a week as a side project. With any other technology (including Smalltalk or Delphi) this would have taken months. As a former Smalltalk developer, what do you think about it would actually slow you down (despite popular claims re productivity in Smalltalk)? Is it tooling for C++ static types? If so, then what about Delphi? And is it one goal of yours, then, to mold Oberon+ so that it would eventually be at parity, productivity-wise, with C++?
    - Rochus 3y ago
      > As a former Smalltalk developer, what do you think about it would actually slow you down (despite popular claims re productivity in Smalltalk)? I was a Smalltalk developer in the early nineties as well, but then switched to statically typed languages and the source file concept for many reasons (performance, testing effort, integratability, etc.). For the present case performance is critical (parsing and cross-referencing of large code base) and also the specific required presentation/interaction features which come with Qt out of the box; and I already have a large toolbox based on C++ which I was able to reuse. > And is it one goal of yours, then, to mold Oberon+ so that it would eventually be at parity, productivity-wise, with C++? It would take more than a lifetime to achieve that goal given that my https://github.com/rochus-keller/LeanQt https://github.com/rochus-keller/LeanQt and https://github.com/rochus-keller/LeanCreator/ https://github.com/rochus-keller/LeanCreator/, which support my efficient toolbox today, have more than a million SLOC. My goal in the first place is to find out how I have to extend Oberon+ so I can use it in real-world (i.e. non-academic) projects with not too big restrictions compared to my current use of C++; reaching parity in terms of efficiency and the therefore required ecosystem is yet another challenge.

by Rochus 3y ago

cyptus 3y ago

is the file filled with 0 bytes at the end? I think there are options to disable this

Rochus 3y ago
Yes, it has about 700 zero bytes at the end; might be just some overhead due to the PE format; didn't have a close look, was just curious how big it is out of the box after skimming the article. Anyway the size of the DLL itself is irrelevant compared to the binaries required to run it (Mono + mscorlib.dll ~ 10 MB in case of Oberon+).

analognoise 3y ago

Nicklaus Wirth was right. I felt that the first time I used Lazarus/FreePascal, and felt it to be true the more of his works I read. Recently though, I think maybe the way to get off the "cycle of reincarnation" for this type of thinking is to do WASM - but I cannot abandon hardware like that. I am mentally incapable of accepting a spiritual machine that I cannot break with a hammer upon my desk; [I am] too primitive; an indestructible global computer that runs on other people's hardware for thousands of dollars of compute time and is slower than an RPi (like Ethereum) is anathema to me in some fundamental way. I still want to get that (Wirth was right) on a shirt with his face on it.

Rochus 3y ago
> Nicklaus Wirth was right In what respect in this context? I should have explicitly stated that "Hello.dll" is a .NET assembly, i.e. Oberon+ uses the Mono CLR to run and debug the Oberon+ code (but not the .NET framework); it can also generate C99 (as a substitute for AOT compilation), but here it is about the minimal size of a Hello World .NET binary. WASM and especially the WAMR runtime might be a good alternative to the Mono CLR in future, but today it's too slow and only a few architectures are supported (much less than Mono).

cxr 3y ago

> It uses the https://github.com/rochus-keller/Pelib https://github.com/rochus-keller/Pelib assembly generator. Shouldn't Oberon+ be self-hosting? There's so much C++ ecosystem crud. It reminds me of all those projects for open source software hosting forges promoted as alternatives to GitHub and Gitlab, and then when you go to clone their code or file a bug... it's all on GitHub...

Rochus 3y ago
C++, in the moderate subset e.g. also used in Qt 1 to 5, I still consider to be the optimal implementation language for a compiler and IDE at the present state of Oberon+ development, not because C++ is such a great language, but because of the ubiquitous availability and the huge, proven code base, which allows me to implement a project like Oberon+ as a single person worlds faster and more robust than with any other technology I know. As an illustrative example of this efficiency, I would like to cite https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPascal, where I was able to implement a parser and code browser within a week as a side project. With any other technology (including Smalltalk or Delphi) this would have taken months. A lot of development is still needed for Oberon+ to reach this point, and using the present approach I can support this development with sufficiently powerful tools.
- cxr 3y ago
  > As an illustrative example of this efficiency, I would like to cite https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPascal, where I was able to implement a parser and code browser within a week as a side project. With any other technology (including Smalltalk or Delphi) this would have taken months. As a former Smalltalk developer, what do you think about it would actually slow you down (despite popular claims re productivity in Smalltalk)? Is it tooling for C++ static types? If so, then what about Delphi? And is it one goal of yours, then, to mold Oberon+ so that it would eventually be at parity, productivity-wise, with C++?
  - Rochus 3y ago
    > As a former Smalltalk developer, what do you think about it would actually slow you down (despite popular claims re productivity in Smalltalk)? I was a Smalltalk developer in the early nineties as well, but then switched to statically typed languages and the source file concept for many reasons (performance, testing effort, integratability, etc.). For the present case performance is critical (parsing and cross-referencing of large code base) and also the specific required presentation/interaction features which come with Qt out of the box; and I already have a large toolbox based on C++ which I was able to reuse. > And is it one goal of yours, then, to mold Oberon+ so that it would eventually be at parity, productivity-wise, with C++? It would take more than a lifetime to achieve that goal given that my https://github.com/rochus-keller/LeanQt https://github.com/rochus-keller/LeanQt and https://github.com/rochus-keller/LeanCreator/ https://github.com/rochus-keller/LeanCreator/, which support my efficient toolbox today, have more than a million SLOC. My goal in the first place is to find out how I have to extend Oberon+ so I can use it in real-world (i.e. non-academic) projects with not too big restrictions compared to my current use of C++; reaching parity in terms of efficiency and the therefore required ecosystem is yet another challenge.