How heavy is the guest code? I mean the optimized code size and RAM consumption. I'm making @fireflyzero, a game console that runs wasm, and I wonder how much resources a C# game would need.
I know! I'm trying to understand how much more. We already have SDKs for Go and Rust but, similar to Exitism, we plan to provide SDKs for other languages as well. If it's feasible to run a C# guest with just a couple of megabytes RAM, we can invest time into adding the language into the officially supported ones.
Time formatting is bad bud luckily most of the time you'll use one of the predefined constants. And when you really need to work with it a lot, there are third-party alternatives: https://blog.orsinium.dev/posts/go/time/
Struct fields and build tags could use a little bit of better standardization, though, with strict syntax and namespacing.
A few weeks back, I showed kid the insides of an Apple 2 and then a box of similarly looking electronic components. He picks out a 7-segment LED and says I want to do something with this.
I'm not sure he knew what he was getting into because all I've got are NAND gates. Figuring out how to represent decimal numbers in binary and displaying a corresponding decimal digit from scratch has proven to be much more involved than it looks. It's actually been a pretty awesome project.
I've done it a while ago! It's a lot of fun if you like math. You make a bool formula for each of the desired states, combine it in one big "or" formula, and then reduce. And this reduction takes most of the time. Putting the hardware gates afterwards is about 20% of total work.
Strange. What's your OS? And regardless of the answer, maybe you can try building in a Linux Docker image and comparing? Let's see if a clean environment gives the right result.
It should give for Linux under 4 Mb for debug builds and under 600 Kb fir release ones. And then there are ways to squeeze more when it matters:
I wonder how many people would be pissed if I started writing things like lambda int1, int2: int instead of typing.Callable[(int,int), int]? A lot I'd bet. Good.
Finished Book 1 (a third) of #Dune by Frank Herbert and it is really good so far, I actually feel that watching the movie helps quite a bit to understand some things, they compliment each other well so far.
The first book is one of the best things I've ever read. The second and the third one not so much. The tone of the story shifts a lot from politics and intrigues to prophecies and religion.
@deshipu "Flat is better than nested" 😉 Besides, maybe I misunderstand you, but all typing-related stuff is already in a separate namespace: the "typing" module (and "collections.abc").
Ada Lovelace was cool, sure. But in the year 2024 maybe find a second woman to name your "women in tech" or "diversity in tech" thing after. Otherwise it looks as if you know exactly one woman.
My number one woman in tech is Barbara Liskov. She introduced lots of seemingly small things that are the basis of most of the modern programming languages (especially #Python and #Ruby): promises, abstract classes, Liskov substitution principle (yes, the name is a giveaway), call by sharing, iterators, parallel assignment, generics, etc. You may not know most of these words but if you write code, you use most of them daily.
Maybe it shouldn't plague this specific dashboard, but I find it very useful to know which functions have 0% coverage. When you have low coverage, it makes sense to first make tests for what functions aren't tested at all ajd only then look at smaller things like uncovered branches or interrupted flow.
Maybe, you can show the size of the longest continuous not covered chunk?
Good idea! The perfect solution is probably a list of functions sorted by the number of uncovered lines. I used to use a golang tool that does exactly that but I can't find it right now.
Shouldn't be too hard! You can get each function's range of lines from AST without a problem, and then just group each line coverage into these ranges.
I'm sure there are! I remember reading the code you wrote for coverage.py, I know it handles lots of things I would never thought of.
The good news is that I just remembered that I already did mapping of coverage to functions a long time before, and I know for sure that for the common case it works great. Here it is: https://github.com/life4/deal/blob/master/deal/_trace.py#L53
I use it in the test CLI command to show the coverage percent for each tested function:
You are the one who made this possible. Or at least much easier. It was a long time ago but I think I borrowed most of the logic for formatting the line ranges from coverage.py:
Decided to try and compare the general base program size of several languages. I wrote a handful of Hello World programs, and stripped them of everything. Here's the final results in KiB:
For #golang, you should try @TinyGo. The main Go compiler is designed to prioritize performance and runtime safety over binary size. But TinyGo is designed for small places.
IDK what's TinyGo Linux binary size for Hello World but we recently optimized a lot for #wasm, and a wasm binary hello world with stripped out debug info is something like 40 bytes.
