Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wuffs’ PNG image decoder

nigeltao.github.io

Post reply on HN
Print view View original

101–110 of 144 posts

Re: Wuffs’ PNG image decoder

#101

Post by _delirium »

Stanzilla wrote: post #97
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

I don't understand why he just doesn't use Rust instead. The speed difference can't be that big.

From reading the docs, one main reason is that they want the output of compilation to be plain C. The Wuffs toolchain source-to-source compiles to plain C source, which can then be compiled and linked anywhere that has a C compiler and/or an FFI to the C ABI, which is a lot of places. Wuffs verifies its safety properties entirely at compile time, so once verified, it can translate the code to completely unchecked C code that is nonetheless known to be safe.

Re: Wuffs’ PNG image decoder

#102

Post by astrange »

quelsolaar wrote: post #22

The check-summing in PnG is poorly designed. It uses 2 different checksum on top of each other. The format itself checksum each chunk, but then the pixel data is using zlibs compression header that have a second checksum on top of that, using a different algorithm.

Most everything about PNG is poorly designed. Using a text codec to encode image data doesn't make any sense even if you pre-filter it. A consequence of this is how much larger PNG files get with alpha, even if the alpha channel has no information in it.

Lossy codecs with lossless modes tend to be a lot more efficient although may be harder to decode.

Re: Wuffs’ PNG image decoder

#103

Post by renox »

Interesting 'single purpose' language though I'm surprised that

1) variables have to be declared before the code (I had to do this a long time ago and it was annoying)

2) the separated section for uninitialised variable in struct, why not =undef like all the other languages?

Also having to use base.u32 everywhere instead of just u32 must be annoying fast.

Re: Wuffs’ PNG image decoder

#104

Post by Jweb_Guru »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

That is true, but on the other hand, Wuffles allows safe unchecked array indexing, which is a very hard problem that Rust doesn't attempt to tackle--in part because it spends most of its complexity budget on the borrow checker! I for one would be extremely interested in using Wuffles in the inner loop of many routines I currently write in Rust which are performance critical, and for which I know bounds checking is hurting performance (sometimes in ways it's hard to convince LLVM to remove), but for which I can't justify the use of `unsafe`. I would particularly love it as an embedded language, rather than one needing a full-blown application.

Re: Wuffs’ PNG image decoder

#105

Post by dahart »

andrepd wrote: post #64
mleonhard wrote: post #61

Earlier quoted context omitted.

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Isn't that stupidly limiting?

Some people consider avoiding heap allocations to be smartly limiting. ;) It’s not really that limiting either, when you learn the techniques for it.

There’s a famous list of NASA’s rules for safety-critical code that you’ll see pop up now and then, that subscribes to the “avoid heap memory allocation” philosophy. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

It’s not nearly as true anymore today, but working in console games 10-20 years ago, it was very common to try to avoid dynamic memory allocation because it was viewed as slow, unsafe, and unnecessary. A common strategy was to statically pre-allocate a single block of the worst-case memory needed for a given feature, because you need to be prepared to hit the worst case without crashing, so you might as well just reserve the max and focus on reducing what the maximum possible usage is.

I once debugged a crash in a console game that was caused by someone trying to be too clever by half with their allocation and copy constructors. We had a team of a dozen people working on the crash through a weekend during crunch because the crash only occurred in a release build on the console dev kit. The cost of this one stupid bug due to using memory allocation could literally accounted for in the thousands of dollars. I basically had to write a mini one-off release-build stack-tracing sampling debugger in order to trap it. So, anyway, long story short, I’m old enough to appreciate why some people suggest that avoiding allocations is a good thing.

Re: Wuffs’ PNG image decoder

#107

Post by zamalek »

andrepd wrote: post #64
mleonhard wrote: post #61

Earlier quoted context omitted.

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Isn't that stupidly limiting?

Seems like an honest question. "Stupidly" is a key word there because humans are, without exception, vastly too stupid to deal with the combinatorial explosion that the heap presents. This is a key goal of languages like Rust: allow the compiler to deal with the complexity for you.

There are vastly fewer interacting elements when you restrict yourself to the stack: basically logic errors and pointer arithmetic become the key concerns (and Wuffs supposedly deals with the latter). Really smart people may be able to completely reason about this space.

Developers are known for imposter syndrome, but we have an unhealthy amount of overconfidence at the same time.

Re: Wuffs’ PNG image decoder

#108

Post by anewhnaccount2 »

com2kid wrote: post #7

My favorite part of the Wuffs github page has to be the definition it gives for Dependent Types > ...Dependent types are a way to implement compile-time bounds checking, but they're not the only way, and there's more to programming languages than their type systems. Wuffs does not use dependent types. Wuffs looks really interesting! I don't think I've ever even heard of a language that is designed to only be used in…

Regex?

Re: Wuffs’ PNG image decoder

#109

Post by ashkankiani »

The author is now a new favorite person of mine. I've been working on my own language, and I have an incredible overlap with the features that Wuff has, specifically the coroutines, refinement types, the "facts" (which I had been inspired to implement from ATS with its proof threading), the io_buffer slice type, and the effects system. It's kind of shocking how much stuff there is on overlap, but it does give a good indication to me that this is a "good idea."

I'm especially pleased with his approach to practicality re: compile times.

I'm also glad it's Apache2 licensed because I'm going to be reading through its source for inspiration at a future point for reference for my own implementations.

I also see a strong likelihood that I will use it extensively for a few projects I had been working on in embedded for the ESP32 on my mobile device prototype and for non-embedded projects with my PL and otherwise (like for my Neovim UI frontend). I'm so glad this was posted.

Post reply on HN