Corrections to the MemoryMeter for all non-Linux platforms #1824
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,11 +51,6 @@ typedef struct Machine_ { | |
| #endif | ||
|
|
||
| memory_t totalMem; | ||
|
|
||
| memory_t totalSwap; | ||
| memory_t usedSwap; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,21 +3,19 @@ | |
| /* | ||
| htop - MemoryMeter.h | ||
| (C) 2004-2011 Hisham H. Muhammad | ||
| (C) 2025 htop dev team | ||
| Released under the GNU GPLv2+, see the COPYING file | ||
| in the source distribution for its full text. | ||
| */ | ||
|
|
||
| #include "Meter.h" | ||
|
|
||
| typedef struct MemoryClass_s { | ||
| const char *label; // e.g. "wired", "shared", "compressed" - platform-specific memory classe names | ||
| bool countsAsUsed; // memory class counts as "used" memory | ||
| bool countsAsCache; // memory class reclaimed under pressure (displayed with "show cached memory") | ||
| ColorElements color; // one of the MEMORY CRT color values | ||
| } MemoryClass; | ||
|
|
||
| extern const MeterClass MemoryMeter_class; | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -60,19 +60,11 @@ static unsigned int DarwinMachine_allocateCPULoadInfo(processor_cpu_load_info_t* | |
| } | ||
|
|
||
| static void DarwinMachine_getVMStats(DarwinMachine* this) { | ||
| mach_msg_type_number_t info_size = HOST_VM_INFO64_COUNT; | ||
|
|
||
| if (host_statistics64(mach_host_self(), HOST_VM_INFO64, (host_info_t)&this->vm_stats, &info_size) != 0) { | ||
| CRT_fatalError("Unable to retrieve VM statistics64"); | ||
| } | ||
|
Comment on lines
-63
to
-75
Member
There was a problem hiding this comment. How does this affect the baseline OS requirements? Also, can we split off this change into its own commit to make reviewing this change easier?
Contributor
There was a problem hiding this comment. We have someone who wants to port htop to iOS 6 (PR #1828) recently. And I don't like this PR contains changes that unnecessarily bump Darwin OS requirements. I bet Nathan (@natoscott) and Pierre-Marie don't have the idea what they're doing. This doesn't count the fact that the memory display now becomes different from what's displayed in macOS top. (this comment) There was a problem hiding this comment. If you bet I have no idea what I'm doing, I could claim I know you don't have the skill level to understand most of what is being discussed here - your inaptitude to understand the problem being the only proof I need. See? I too can make derogatory comments: admire how it adds constructively to the discussion. Want to continue? I'd have plenty of things to say on the way you manage benevolent contributions to your project from other people, of which a psychoanalyst would likely diagnose a certain sense of intellectual insecurity. How does it feel? Want to continue again? Or we stop here and engage in a more productive conversation? Facts.
Now on a more professional tone. This deletion was made in a spirit of simplification. If adding 32-bit iOS support to the htop code should be considered, then simply put these #ifdefs back. No need to insult or defame the contributors. One last remark: if someone wants in Q4 2025 to add support to an ancient version of an OS on a deprecated architecture, he/she likely already has the skills to do it himself and add the missing pieces back. Any code that's #ifdef'ed out 99% of the time the project is built and that you leave here for legacy reasons is a technological debt, that you will bear the responsibility to maintain. I could troll you seriously here, with more irony about your role as a maintainer, please note that I choose not to. I expect you to do the same, or adopt the only responsible alternative.
Contributor
There was a problem hiding this comment.
Dropping compatibility to legacy systems without stating a good reason is a bad attitude to many free and open source projects. I'm aware that the legacy code may be a "technological debt", but other than the reasons of "it's broken for a long time" and "it's a substantial effort to maintain the compatibility code that it may not seems worth it", I'm not seeing any other good reason for removing it. I never support the attitude from those big, proprietary corporations that they can arbitrary drop support for old hardware or systems (look at Microsoft and Windows 11, for example), and expect consumers/end-users to get over it. There was a problem hiding this comment.
These are, precisely, two most excellent and self-sufficient, reasons to do it. But as I said elsewhere, this is your project - you do what you want.
Member
There was a problem hiding this comment. To both of you: Please at least try to stay professional for a moment. (@Explorer09 We had a discussion about these kinds of comments off-site. I'm not here to babysit you and would appreciate if we keep things without personal attacks/insults.) Back for the actual topic. Personally I'm open to move forward in either direction, without any preference. Thus my initial question in this thread, how dropping the Quick aside on the backward compatibility: For the Linux port we intentionally keep support for kernels without support for |
||
| } | ||
|
|
||
| void Machine_scan(Machine* super) { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,11 +19,7 @@ typedef struct DarwinMachine_ { | |
| Machine super; | ||
|
|
||
| host_basic_info_data_t host_info; | ||
| vm_statistics64_data_t vm_stats; | ||
| processor_cpu_load_info_t prev_load; | ||
| processor_cpu_load_info_t curr_load; | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I preferred when explicit color names were used (DYNAMIC_RED, etc). Explicit color names gave at least a chance for the contributors wishing to bring in support for another platform to map the same colors to roughly equivalent memory classes where that possibility exist, and use other colors where it doesn't. Having numbered opaque names is uninformative and thus unhelpful IMO. If you don't want explicit color names, perhaps give more descriptive labels that correspond to the ASCII character that's drawn by ncurses on monochrome terminals. e.g. MEMORY_CHAR_HASH, MEMORY_CHAR_DOLLAR, etc. It makes tracking similar choices easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PierreMarieBaty The ASCII characters drawn in monochrome mode of htop is not assigned by ncurses, but by htop itself. The character list is defined in Meter.c.