5 ms·

bflat author here - happy to answer questions. I think at this point https://flattened.net/ https://flattened.net/ is a better introduction to bflat than the r

bflat author here - happy to answer questions. I think at this point https://flattened.net/ https://flattened.net/ is a better introduction to bflat than the repo. The repo also links to it, but wanted to highlight it.

throwaway_au_1 4y ago
Awesome project! C# is my preferred language, but I love the less-heavyweight tooling in other langs, so bflat fits nicely. What inspired you to start this / what was your use case? Where did existing tooling fall short for you? I had a brief look at the repo but didnt see a 'Why' or similar section.
- MStrehovsky 4y ago
  I also like the less heavyweight approach where one can compose tools to do things. The existing .NET tooling is so entwined with MSBuild that one can't even (easily) invoke the C# compiler without an MSBuild project file. Don't get me wrong, I like MSBuild and even bflat is built with MSBuild (wrote a custom target to invoke bflat from MSBuild), but sometimes I really just want to write a Makefile and be done with it instead of fiddling with MSBuild targets. bflat integrates nicely with Make or other build systems - pass `-c` to generate object files (link it later with the commands bflat would use - use `-x` to see the commands), or use `bflat build-il` to create .NET assemblies and pass those as a reference (`-r`) to `bflat build` later.
adamredwoods 4y ago
Any thoughts on OSX support? I'm naive here, but DotNet 6 seems to work just fine (I haven't tried building bflat yet), and p/invoke seems straightforward enough: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int...
- metaltyphoon 4y ago
  I think that support will come when dotnet 8 adds aot support for osx.
- MStrehovsky 4y ago
  I want bflat to be able to crosscompile from anything to anything. Apple's platforms are difficult to crosscompile for - most instructions I've seen that need to reach dependencies beyond what libc offers require one to copy files from an Xcode installation and pray one didn't break EULAs. I don't even know where to start if I want to build from Linux or Windows to target macOS without a mac. Then there's a philosophical issue that I have where Apple essentially would like everyone to pay up if they want to distribute software that targets their platforms (required code signing, etc.), and breaking backwards compat all the time (essentially treating developers like a resource to be exploited). This practice needs to go away. I know bflat not being available for macOS won't change that, but we need to start somewhere...
  - jeswin 4y ago
    I agree with what you're saying, and it's of course entirely your call to make. However, given that a significant percentage of developers are on Macs, this makes bflat a non-option for a large number of use cases. Even if I'm writing a library (and not an app or a service), I can't pick bflat because sooner or later someone will want to target Macs and iOS. Also, will .Net V8 NativeAOT being able to target Apple Silicon help with the effort?
  - ithkuil 4y ago
    Can you do whatever Go does? IIRC Go can crosscompile without requiring any xcode component. Or you literally mean that you don't want to do it because of ideological reasons regardless of the aforementioned technical argument?
    - MStrehovsky 4y ago
      The crosscompilation on Go to mac is pretty limited. That's why I wrote "need to reach dependencies beyond what libc offers". If you crosscompile Go from Linux to mac, you'll actually get a different binary than if you compile on mac natively (DNS resolution will use Go's home baked version instead of the one provided by the OS). CGo also doesn't work if you crosscompile. It's a bunch of work to even get a hobbled version of crosscompilation to macOS running.
rkagerer 4y ago
What's keeping exceptions out of Zero? Is there a simpler way you could achieve Try/Catch semantics and throw-like flow control, without having to check return values after each function call? eg. Even though VB6 lacks exceptions, I built such a framework for it out of primitives like "On Error Goto" (and helper tooling that would automatically wrap and instrument functions to propogate the Err details). It sounds a bit heavy but was in fact really slick in practice.
- MStrehovsky 4y ago
  TL;DR: It's work. The way exceptions are done in .NET is by keeping track of extra metadata to be able to unwind methods (remove them from the execution stack) and execute handlers. That way the overhead of exception handling is close to zero if no exception is ever thrown. This requires quite a bit of infrastructure. Propagating exceptions as error codes would come with execution time costs even if no exception is thrown and would have to be written from scratch (since .NET doesn't do it this way). Either approach requires more investment than I'd want to put into it right now.
- kevingadd 4y ago
  Note that .net supports exception filters (and the stdlib uses them), so replacing exceptions with error codes would observably change behavior in a big way.
superjan 4y ago
Hi. I think this is an exciting development. It will be much work to replicate all dotnet standard libraries. Is there anything existing that can be ported/reused? For instance the original work on mono? Or is any of microsoft’s work licenced permissible enough to use?
- MStrehovsky 4y ago
  This is using Microsoft's standard libraries and compiler parts. All of .NET is MIT licensed so this kind of remixing is super easy.
  - superjan 4y ago
    Thanks.
orra 4y ago
Ah, there's a repo. That's cool: I didn't realise you'd open sourced this.
signaru 4y ago
Awesome work! Any info about UI frameworks that are/might be supported?
jordo 4y ago
Would you be able to provide support for dotnet 8 alpha? Super interested in this, but would need iOS,MacOS and wasm... Seems like cross-compile support for all those targets are already in 8.0.0 alpha?

throwaway_au_1 4y ago

Awesome project! C# is my preferred language, but I love the less-heavyweight tooling in other langs, so bflat fits nicely. What inspired you to start this / what was your use case? Where did existing tooling fall short for you? I had a brief look at the repo but didnt see a 'Why' or similar section.

MStrehovsky 4y ago
I also like the less heavyweight approach where one can compose tools to do things. The existing .NET tooling is so entwined with MSBuild that one can't even (easily) invoke the C# compiler without an MSBuild project file. Don't get me wrong, I like MSBuild and even bflat is built with MSBuild (wrote a custom target to invoke bflat from MSBuild), but sometimes I really just want to write a Makefile and be done with it instead of fiddling with MSBuild targets. bflat integrates nicely with Make or other build systems - pass `-c` to generate object files (link it later with the commands bflat would use - use `-x` to see the commands), or use `bflat build-il` to create .NET assemblies and pass those as a reference (`-r`) to `bflat build` later.

adamredwoods 4y ago

Any thoughts on OSX support? I'm naive here, but DotNet 6 seems to work just fine (I haven't tried building bflat yet), and p/invoke seems straightforward enough: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int...

metaltyphoon 4y ago
I think that support will come when dotnet 8 adds aot support for osx.
MStrehovsky 4y ago
I want bflat to be able to crosscompile from anything to anything. Apple's platforms are difficult to crosscompile for - most instructions I've seen that need to reach dependencies beyond what libc offers require one to copy files from an Xcode installation and pray one didn't break EULAs. I don't even know where to start if I want to build from Linux or Windows to target macOS without a mac. Then there's a philosophical issue that I have where Apple essentially would like everyone to pay up if they want to distribute software that targets their platforms (required code signing, etc.), and breaking backwards compat all the time (essentially treating developers like a resource to be exploited). This practice needs to go away. I know bflat not being available for macOS won't change that, but we need to start somewhere...
- jeswin 4y ago
  I agree with what you're saying, and it's of course entirely your call to make. However, given that a significant percentage of developers are on Macs, this makes bflat a non-option for a large number of use cases. Even if I'm writing a library (and not an app or a service), I can't pick bflat because sooner or later someone will want to target Macs and iOS. Also, will .Net V8 NativeAOT being able to target Apple Silicon help with the effort?
- ithkuil 4y ago
  Can you do whatever Go does? IIRC Go can crosscompile without requiring any xcode component. Or you literally mean that you don't want to do it because of ideological reasons regardless of the aforementioned technical argument?
  - MStrehovsky 4y ago
    The crosscompilation on Go to mac is pretty limited. That's why I wrote "need to reach dependencies beyond what libc offers". If you crosscompile Go from Linux to mac, you'll actually get a different binary than if you compile on mac natively (DNS resolution will use Go's home baked version instead of the one provided by the OS). CGo also doesn't work if you crosscompile. It's a bunch of work to even get a hobbled version of crosscompilation to macOS running.

rkagerer 4y ago

What's keeping exceptions out of Zero? Is there a simpler way you could achieve Try/Catch semantics and throw-like flow control, without having to check return values after each function call? eg. Even though VB6 lacks exceptions, I built such a framework for it out of primitives like "On Error Goto" (and helper tooling that would automatically wrap and instrument functions to propogate the Err details). It sounds a bit heavy but was in fact really slick in practice.

MStrehovsky 4y ago
TL;DR: It's work. The way exceptions are done in .NET is by keeping track of extra metadata to be able to unwind methods (remove them from the execution stack) and execute handlers. That way the overhead of exception handling is close to zero if no exception is ever thrown. This requires quite a bit of infrastructure. Propagating exceptions as error codes would come with execution time costs even if no exception is thrown and would have to be written from scratch (since .NET doesn't do it this way). Either approach requires more investment than I'd want to put into it right now.
kevingadd 4y ago
Note that .net supports exception filters (and the stdlib uses them), so replacing exceptions with error codes would observably change behavior in a big way.

superjan 4y ago

Hi. I think this is an exciting development. It will be much work to replicate all dotnet standard libraries. Is there anything existing that can be ported/reused? For instance the original work on mono? Or is any of microsoft’s work licenced permissible enough to use?

MStrehovsky 4y ago
This is using Microsoft's standard libraries and compiler parts. All of .NET is MIT licensed so this kind of remixing is super easy.
- superjan 4y ago
  Thanks.

orra 4y ago

Ah, there's a repo. That's cool: I didn't realise you'd open sourced this.

signaru 4y ago

Awesome work! Any info about UI frameworks that are/might be supported?

jordo 4y ago

Would you be able to provide support for dotnet 8 alpha? Super interested in this, but would need iOS,MacOS and wasm... Seems like cross-compile support for all those targets are already in 8.0.0 alpha?