|
Wordle 617 5/6
โฌ๐จโฌโฌโฌ
๐จโฌ๐จ๐จโฌ
โฌโฌ๐ฉ๐ฉ๐จ
๐ฉโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
|
|
|
|
|
Wordle 617 4/6
โฌโฌโฌโฌ๐จ
โฌ๐จ๐จ๐จโฌ
๐จ๐จ๐จโฌ๐จ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Greens only on last row.
|
|
|
|
|
Wordle 617 3/6*
โฌ๐จโฌ๐จโฌ
๐ฉ๐จ๐จ๐จโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
โฌ๐จโฌโฌโฌ
โฌ๐จ๐ฉ๐จโฌ
๐ฉโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming โWow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 617 5/6
โฌโฌโฌโฌโฌ
โฌโฌ๐ฉ๐จโฌ
๐ฉโฌ๐ฉ๐ฉโฌ
๐ฉโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 617 4/6
โฌโฌโฌ๐จโฌ
๐ฉโฌโฌโฌโฌ
๐ฉ๐จโฌโฌโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Just came into view
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
#Worldle #400 2/6 (100%)
๐ฉ๐ฉ๐ฉ๐จโฌโ๏ธ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ๐
https://worldle.teuteuf.fr
Knew was in caucus region but could recall the names so I peeked.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I'm getting 10 gmail spam messages a day. I can't seem to find anytging on Google or in GMail settings about dealing with spam. Anyone know of anything?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
All of the sudden I'm no longer stumbling, and I've broken into a run.
Got my user interface library UIX up and functional. Well, a button control and a label control anyway, but that includes the considerable foundations to make it work.
Just an alpha blended button and a label
UIX initial demo - YouTube[^]
Fortunately it's downhill from here.
It feels good to have the rough parts of this behind me.
I've never done this before. I think I did okay.
I'm pretty proud of the rendering code below
uix/uix_screen.hpp at master ยท codewitch-honey-crisis/uix ยท GitHub[^]
Productive weekend.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Nice!
I love those days when I fly but today I'm grounded...nothing has gone right.
|
|
|
|
|
You are shaking a bit. Excited!
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
No, just shaky
To err is human. Fortune favors the monsters.
|
|
|
|
|
Magnified view will make it shaky.
You really work down in the weeds on your hardware and software.
Actually pretty cool to see it in action at that level.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Is it OK for you?
I never used, so far, but wondering about.
(This is NOT a programming question  )
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
If you mean things like malloc(), yes and no.
Heap fragmentation is a constant battle because you're dealing with very little SRAM.
Therefore, you need to be strategic about your allocations. Allocate, use, toss, as quickly as possible, OR allocate a large buffer initially, and then work from that.
I'll assume C++ below, though the above principles apply to things like C as well.
One caveat is you don't usually have debugging facilities, so it can be difficult to find leaks. Judicious use of the RAII pattern should take care of this. I usually delete copy constructors and implement move constructors for most of my classes that allocate to avoid casual allocations.
You'll probably want to avoid using The STL since they didn't really consider constrained memory environments when they made it - it whips the heap with a lot of little allocations. It *is* possible to cajole The STL into using a custom allocation scheme but there's also the issue of The STL not always being fully available, such as on 8-bit platforms, so I usually avoid it unless I'm targeting a particular platform and I know it supports it, if that makes sense.
The bottom line is: Be careful, be strategic, and you'll be okay.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Yes, I mean malloc and the like (in fact, since I saw malloc in your code I am wondering about...).
Thank you.
I am curious to know if someone uses a custom allocator.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I tend to use malloc because many platforms have custom allocators to allocate things like external memory.
For example, on the ESP32 you can allocate from extended RAM (PSRAM) by using ps_malloc instead of malloc.
By accepting a void*(allocator)(size_t) pointer as an argument to my constructor for example, I can use custom memory. With new and delete or even calloc that becomes problematic, as there are no corollaries.
That's primarily why I use malloc in so much of my C++ rather than the C++ish alternatives.
It's kind of an aside to what you were asking, but may be of some significance to you. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: With new and delete or even calloc that becomes problematic, as there are no corollaries.
I don't get this, since you might, for instance, use your own allocator in new.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I should have been more clear.
Sure if you do that it would work, but with new there are also other issues. It's not always possible/ideal to use new, such as for example, when you need to allocate an uninitialized array of bytes. It's not a good idea to preinitialize a gob of memory you're going to be overwriting entirely anyway, such as bitmap data. No sense in clearing it if you're just going to fill it with purple as your next step. This gets important on little CPUs.
Also, it's actually easier in practice to tie an allocator to a function pointer and keep things consistent. new can be overloaded inside classes with different behavior. I haven't really thought about the ramifications of that, in terms of a graphics library on IoT, where different memory has different characteristics but it smells to me, as though it would create confusing bugs - allocating from PSRAM in one instance because you call it from somewhere else where it would usually allocate from SRAM.
To err is human. Fortune favors the monsters.
|
|
|
|
|
CPallini wrote: I am curious to know if someone uses a custom allocator.
Back in the day for my 'limited' systems (64k to 1 meg)
# I wrote my own heap for use in C replacing what was there. Replacement managed different sizes.
# I wrote my own C++ allocators. That was to manage strings (my class) more efficiently.
I also wrote my own virtual memory manager for a limited use role to switch in and out code for printing a graph (if I recall correctly.)
|
|
|
|
|
Wow.
You should write one article (or possibly many articles) on the argument. 
I need to perceive full control, but a little scared of writing my own one.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I always avoid it: my realtime stuff is always expected to run 24/365, so any heap fragmentation is a major problem. I allocate ram at init or preferably compilation, and it doesn't change from there, except for the stack obviously.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That was I've done so far. However, systems are getting more complex...
Thank you.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I've found that you can create robust systems that malloc just fine as long as you're careful.
I mean, I'm not saying you shouldn't avoid it, but used judiciously you can get away with it without having to worry that your code will crash a week in.
Basically, you allocate small amounts and throw them away quickly.
Then if you're really concerned you can profile to make sure you aren't leaking and have enough headroom, but in practice I don't even find I need to do that most of the time.
Edit: If you use common libraries like LVGL to provide a user interface for example, those will often malloc in the background.
To err is human. Fortune favors the monsters.
modified 26-Feb-23 4:55am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
