|
|
|
I assume you already use all them GCC flags:
"When compiling -ffunction-sections and -fdata-sections, when linking -Wl,--gc-sections,--print-gc-sections "
from that unmentionable source.
The link just above it suggests analysing the exportable AST from Clang. Now that sounds like your kind of project!
I would've thought such a tool is easier to base on the AST (i.e. static code analysis) than the final code, optimzed or not. But then I might be missing something.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Curtis & Leroy saw an ad in the loal paper and bought a mule for $100.
The farmer agreed to deliver the mule the next day.
The next morning the farmer drove up and said, "Sorry, fellows, I have some bad news, the mule died last night."
Curtis & Leroy replied, Well, then just give us our money back."
The farmer said, "Can't do that. I went and spent it already."
They said, "OK then, just bring us the dead mule."
The farmer asked, "What in the world ya'll gonna do with a dead mule?"
Curtis said, "We gonna raffle him off." The farmer said, "You can't raffle off a dead mule!"
Leroy said, "We sure can! Heck, we don't hafta tell nobody he's dead!"
A couple of weeks later, the farmer ran into Curtis & Leroy at the Piggly Wiggly grocery store and asked.
"What'd you fellers ever do with that dead mule?"
They said, "We raffled him off like we said we was gonna do."
Leroy said, "Shucks, we sold 500 tickets for two dollars apiece and made a profit of $998."
The farmer said, "My Lord, didn't anyone complain?"
Curtis said, "Well, the feller who won got upset. So we gave him his two dollars back."
|
|
|
|
|
Mike Hankey wrote: made a profit of $998.
$898. FTFY.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It's that southern math, he ran out of fingers and toes. 
|
|
|
|
|
If he can't count to 1024, he's got less than 10 fingers and toes in total. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
My graphics library for embedded devices has to deal with pixel formats I don't know ahead of time because the devices are diverse, and in order to be efficient pixels must be represented in their native bit format at all times. In other words, a pixel should store its values in whatever underlying format best suits the device or data stream
To complicate things, not all channels are color channels, (think alpha channel for transparency) and not all channels are the same bit width. (rgb565 16 bit color for example)
There are also totally weird ones that are common like rgb666/18 bit format (262,144 colors)
And not all devices use the same byte order in their streams.
To complicate things further, not all devices use an RGB color model. To my surprise I found out that some devices are BGR, regardless of byte order. Meanwhile, JPEGs are (IIRC) CMY or CMYk! Also critical because that's the input format from cameras, which are commonly used with these devices.
What is a pixel?
It's color space, which includes color model. It's binary layout. It uses potentially highly heterogenous channels for its data.
A pixel is as complicated as a unicode character! 
And I can't be messing with most of this in RAM, nor at runtime. Nope, most of it needs to be not only resolvable at compile time, but the dead code generated from all the metaprogramming involved needs to be removable by the compiler to avoid code bloat on these tiny devices.
One example is retrieving values, which I have generic getters and setters for (using metaprogramming) that generate the necessary masks and shifts at compile time based on the variable series of pixel_channel_traits you gave it and channel index, each which have their own bit depth, so retrieving and setting the channels individually gets complex.
My code can resolve it all at compile time. I feel like a hero. 
I wouldn't need to do this if there was some sort of unified driver model for these things.
But all the meta programming in C++ is cool. I really hadn't caught up with C++11 variadic templates and such until now. They're neat!
An rgb565BE pixel definition:
typedef pixel_channel_traits<uint8_t,5,pixel_channel_kind::color> color5_channel_traits_t;
typedef pixel_channel_traits<uint8_t,6,pixel_channel_kind::color> color6_channel_traits_t;
typedef pixel_traits<
uint16_t, pixel_color_model::rgb,
false, color_5_channel_traits_t, color_6_channel_traits_t, color_5_channel_traits_t> rgb565be_traits_t;
This actually generates proper getter and setter methods off the int_type, and gives you a union between the int type, and an array of bytes representing the data. It's complicated and weird code - and all of the pixel template classes (above are *trait* classes associated with the pixel template classes) which add indexed getter and setter methods for the channels that get/set a floating point value between 0 and 1, so you can operate on them generically regardless of format if you need to which is useful for things like color conversion. 
Real programmers use butterflies
modified 13-Mar-21 5:29am.
|
|
|
|
|
honey the codewitch wrote: Meanwhile, JPEGs are (IIRC) CMY or CMYk!
Variations of YCbCr - Wikipedia[^]
|
|
|
|
|
Whoops, mea culpa
*adds yet another enumeration entry to the color model*
thanks for catching that!
Real programmers use butterflies
|
|
|
|
|
Did you read the standard I posted? The Lounge[^]
It's all there, block sequences, encoding and everything.
Incredibly boring, but complete afaik.
|
|
|
|
|
User: "Can you make that button green?"
Normal developer: "Sure, no problem."
You: "Well..."[^]
|
|
|
|
|
Sander Rossel wrote: User: "Can you make that button green?"
No, I do development, not design.
Always kept away from colors and made those configurable.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I came across this article. Is Xamarin really dead? If so, aside from MAUI, what other options are there for Mobile development?
I'm planning on doing an Android app, and I like working in Visual Studio.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I was under the impression that MAUI effectvely is Xamarin Forms evolved. So I guess if you need to code now then go for the most recent platform you can: MAUI or Xamarin Forms.
Er.... I think. Correct me if I'm wrong anyone. I'm still trying to get my head round Microsoft's future platforms.
|
|
|
|
|
From Feature Roadmap · xamarin/Xamarin.Forms Wiki · GitHub[^] as of 1st March:
Transition to .NET MAUI
July 15, 2020 Pull Request Policy Changes
As noted below, Xamarin.Forms 5.0 is due out at the end of September. At that time we will re-sync dotnet/maui and work on preparing our first preview release of .NET MAUI. In order to be considered for release by or before Xamarin.Forms 5.0, feature pull requests should be submitted for review by July 15.
After July 15, any new feature pull requests may still be submitted to this repository (xamarin/xamarin.forms). We will label those for migration to dotnet/maui. Be aware that the bulk of renderer refactoring will happen after Xamarin.Forms 5.0, so contributions to controls and renderers may require refactoring.
Pull requests to fix issues will continue to be reviewed through November 2022, and sync'd with dotnet/maui using a combination of automation and manual implementation.
The text above has now been replaced with this:
Current Version
Xamarin.Forms 5.0.0 is the current stable release. Release notes
We will continue to service Xamarin.Forms 5 through November 2022.
Next Major Version - .NET 6
The development of our next major version is underway at dotnet/maui. .NET MAUI will ship with .NET 6, now in preview.
Your existing and new Xamarin.Forms applications will migrate to .NET MAUI with tooling assistance and documentation which we will provide later in the .NET 6 preview timeframe.
Also see MAUI in .NET 6: Xamarin.Forms Does Desktop, but Not Linux or VS Code -- Visual Studio Magazine[^].
|
|
|
|
|
Thank you!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Kevin Marois wrote: Is Xamarin really dead?
Yes.
Failed marketing.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Marketing alone can't bridge failed effort.
I've considered picking up Xamarin for 3 different projects during the course of it's existence. Never did.
The appeal of Xamarin was having a C# compatible front-end that could replace SilverLight in the LoB space.
In theory, XAML components could be written and tested for WPF desktop use, and then be ported to mobile platforms with low overhead costs.
Or, to put it pragmatically: it made Android and iOS expansion look cheap if you where doing WPF at the time.
In practice, the benefits just never materialized.
They used Mono as their C# framework, which is probably what killed them in the end. Mono is great for running arbitrary C# code, but it doesn't support WCF and a bunch of other business-oriented one-offs that are cheaper to propagate than to replace.
Their XAML was a dialect, so none of the major XAML designers could create Xamarin compatible components, making the use of XAML entirely pointless from a budget perspective.
At the time, I really thought they would contribute to XAML Standard 1.0, or at least align with a XAML designer.
But, as time went on, it seemed like they doubled-down on their core-value without ever really having one.
|
|
|
|
|
You need to consider that the article is written by a services company that wants it dead. Of course it will find all sort of reasons (some far from the truth: Xamarin developers hate it, Rider is the editor, really?!) that is dead and point you to the direction it wants - from their website, flutter and native.
Viewing the issue objectively, I think the future of Xamarin is in-line with the future of .NET - unifications - and it will not just die (as some might want). If that is called Xamarin, MAUI or whatever, that's just marketing term.
Obviously, things change as they evolve and some things might be dropped but I highly doubt it Xamarin Forms based apps will just stop working or won't be migrated.
It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.
Eusebiu
|
|
|
|
|
"It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.".
Microsoft may be a better bet but that doesn't mean that you might not someday still be left behind.
Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
|
|
|
|
|
Quote: Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
Don't get me started. I'm a VB.NET web developer. After years of being told that language selection was a "life-style choice", I'm now being told that for web development C# is the only option moving forward.
--A. Lovhaug
|
|
|
|
|
I wasn't very excited about the switch to C# but it ended up taking about 3 days.
|
|
|
|
|
MadGerbil wrote: I wasn't very excited about the switch to C# but it ended up taking about 3 days.
I could, but my plan is to go a different route as I'm a freelancer and my customers don't care about the technology choices. Instead, I intend to switch to RemObjects Mercury, which is almost fully compatible with VB.NET, plus supports many platforms, including ASP.NET Core, WASM, iOS, Android, and Linux development. Currently in beta, and the company is very responsive.
--A. Lovhaug
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
