Example?
336 karma · joined January 7, 2023
3 decades.
Dehydration is not a confounder for an A1c test since the percentage is relative to the hemoglobin present. The primary confounder to A1c are blood disorders such as hemolytic anemias that lower the normal lifetime of RBCs or proportion of HbA. And this tends to falsely lower the A1c.
A person with an 11% A1c is also likely drinking quite a bit (whether they notice it or not) because at that point the chronically elevated glucose is elevating serum osmolality to increase urination.
Why not just use an FPGA?
These NOTAMs were designed for human consumption and brevity, they date back to the 40s (debate about their ergonomics nonwithstanding).
Ok this doesn’t dispute what I’m saying at all and I would think you would know better. Do you have profiles from 15 or so years ago that show text rendering was a substantially smaller percentage of time.
And if you do - ensure it is comparing apples to apples with subpixel (or at least greyscale) hinting and full featured shaping. Neither of these are related to blitting/blending performance but they are relatively expensive.
Modern text rendering is super expensive (but by modern we’re talking on the order of 15 to 20 years, not yesterday). People are making claims that CPU 2D rendering has gotten more sluggish in that time frame - though nothing fundamental has changed other than the prevalence of “Retina” in some circles - but that isn’t something that has scaled past CPU performance. This all works because historically these systems have been painstaking about only drawing when needed what’s needed.
If anything has changed it’s that - software in general for a number of reasons has gotten much sloppier about this.
And in the case of Mac OS specifically - they continue to throw all kinds of shit in the CPU rendering pipeline. If you just do things yourself and blit to a Metal texture, nothing is fundamentally slower.
I contend that most of what people are claiming are some fundamental hardware changes (that haven’t happened - things are faster across the board but otherwise it’s the same basic stuff) is due to less effective application software methods. For 2D desktop apps the GPU is not the factor some people seem to think it is.
And people throw 15 to 20 years ago like it was a long time ago - but OSX Jaguar is more than 20 years old now (that’s the version that brought the current design of 2D desktop rendering with a compositing window manager to Mac OS X)
“Once widely used chemical in the 70s…” or a “Formerly widely used chemical” - was that so hard?
They don't do GPU font rendering either.
Pathfinder isn't widely used -- see my original post about "spinning wheels".
GPU font rendering hasn't demonstrated much real world value for GUIs. Where it does get used a bit is games - an industry that is overwhelmingly C++ for the foreseeable future.
> No? They are discussing Simd and generic interactions.
I was responding to this: "I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++."
Regardless, Rust still depends entirely on the years of research and development in C++ for a memory model which is a core underpinning of parallel programming.
https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo...
https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo...
Also neither of your examples do any text shaping on the GPU. Lyon doesn’t do text and Webrender (which depends on freetype) does regular old glyph cache built in CPU texture rendering. Neither involve GPU shaping.
https://github.com/servo/webrender/blob/master/wr_glyph_rast...
Still trying to understand what earth-shattering, "leverage" levering feature this brings compared to Skia.
> Memory model of Rust is undefined[2]. It might be anything Rust does to accomodate C++ bindings, but I don't think they really settled on one.
> I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++.
Do you not see at least some level of contradiction to these statements?
This is probably the more relevant explanation: https://doc.rust-lang.org/nomicon/atomics.html. "At very least, we can benefit from existing tooling and research around the C/C++ memory model."
Perhaps respect your elders a bit more?
Maybe. Gtk and its related libraries don’t cover everything Qt does, but they’re not small either. It’s also fair to include the native toolkits themselves on their respective platforms that are written in a mixture of C++/C/Objective C.
I also will point out that one of the cross platform toolkits with some traction in the Rust world is amusingly fltk.
> What grandparent probably means something that leverages parallelism and/or GPU acceleration.
You mean like QtQuick/QML, skia (basically this is the effective underpinning of electron and flutter) or Dear Imgui, etc. There are a handful of widely used GPU based GUI libraries. The above examples are all C++.
> leverages parallelism
The memory model of Rust is still whatever C++ does. I get that Rust has some nice features and C++ makes it easy to fuck your self but people have been doing large scale parallel software development for years in C++.
> Qt is also old as Jesus, and making a cross OS GUI is extremely hard.
The claim was we are in a new era of “leverage” that will make the hard very easy (that’s what it sounded like at least). I found the claim at best vague and low on specifics or evidence - hence the mention of RESF.
Based on the way the Rust community has been spinning its wheels for years in getting something even within a light year of feature parity with Qt, if a new era has truly dawned you might need to wait for the next one.
> Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software.
I like Rust - but this is classic RSF/RIIR copypasta.
Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology.
> This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms
Having written cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists.
> It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar.
Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
> How much do you think his more than a thousand different electric components for PCBs would cost, just by itself?
Easily less than $500 based on the items there's a glimpse of - probably much less.
> Do you think he buys each one in bags of 1?
I doubt it - that would be utterly stupid for passives and this guy doesn't seem stupid - if anything obviously frugal to a fault. I think there are too many corners cut - there is some bench equipment that is worth splurging a bit on. But even when you buy small quantities of SMT components they are usually cut off a tape - and in the US sold for a huge ass markup. It seems his bagging and inventory system is homegrown.
It is somewhat telling that there is more money paid on the computer - this is more a computer enthusiast who dabbles in electronics setup (not that there is anything wrong with it) - but if you're doing serious circuit design work you're going to find this setup lacking in many ways.
Well that should be easily relatable then.
> There are far more ways to write javascript than any of us want.
Some of the examples you cite are due to JavaScript being minimalist though. For object creation there are a few different syntactic methods but it is straightforward how they compare semantically - they are basically equivalent. C++ has numerous methods to do similar things but they each have their own numerous rules and exceptions. Ironically in C++ there is often only one way to do something a certain way, as a similar syntax for initialization may (not will) do something completely different depending on external context - such as merely putting parens around a set of braces.
The diagnostic output of the compilers alone when you misplace a symbol is longer than many JavaScript libraries.
> But it’s big enough that almost nobody knows every javascript feature.
I don’t think this is true. It just isn’t that big of a language. The examples given certainly don’t paint a picture of immense complexity - a few things have accreted during the years, it’s not outside of simply just learning them in a few weeks.
It’s not just about the length of the spec (which is much shorter) but the complexity of those specified features within the system as a whole - JS as a system just isn’t relatively that complex.
> the language probably still isn’t as big as C++.
For anybody that does modern C++ and JavaScript professionally (as opposed to those that are content continuing to write C++ like it’s CFront) this is a coffee spitting understatement.
Read TFA?
The person I was replying to was talking about supermarket sold mass produced confections, and my response was valid, not based on personal experience and can be easily verified. For most of those things shrinkflation is the predominant force. Ice cream packaging sizes and prepackaged cookies haven’t gotten larger. And if anybody is surprised that these products are loaded with refined sugar (then as now) that’s on the public education system. The fats used have may have changed.
Restaurant portion sizes and content have increased but that’s a different problem. Same as dispensed soft drinks.
> gotten softer and easier to eat.
What does this even mean?
Hostess foods famously went out of business a few years ago. When I think “soft” and calorie dense I can’t imagine any time more representative than the 50s and 60s.
This is an unwinnable conflict between population medicine and policy and individual choice.