Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 09:00:55 -0400 Michael Jennings [EMAIL PROTECTED] wrote: On Thursday, 21 July 2005, at 11:59:54 (+0200), Martin Geisler wrote: Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? Boy I hope not. Such nonsense has no place in Enlightened software. I think it makes things clearer in the long run if we begin using these units. No it doesn't. When you're dealing with bytes, units are multiples of 1024 instead of 1000. It doesn't get any clearer than that. Well, it IS a nonsense, but everyone already get used for 1024 multiplies, I think it is a bit too late for changing this. Only effect will be more clueless people. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 15:22:14 (+0200), Jackob McRose wrote: Well, it IS a nonsense, but everyone already get used for 1024 multiplies, I think it is a bit too late for changing this. Only effect will be more clueless people. Resistance is NOT futile. You do not have to be assimilated. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- With every kiss our love is like brand new, and every star up in the sky was made for me and you. Still we both know that the road is long. But we know that we will be together because our love is strong. -- Firehouse, Love of a Lifetime --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Michael Jennings [EMAIL PROTECTED] writes: On Thursday, 21 July 2005, at 11:59:54 (+0200), Martin Geisler wrote: Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? Boy I hope not. Such nonsense has no place in Enlightened software. I think it makes things clearer in the long run if we begin using these units. No it doesn't. When you're dealing with bytes, units are multiples of 1024 instead of 1000. It doesn't get any clearer than that. Well, reading through the Usage Notes section on Wikipedia is interesting. We're dealing with bytes in all six cases, but there are differences: * A MB of RAM is 1024 * 1024 bytes. * A MB on a harddisk is 1000 * 1000 bytes if you're the manufacturer, but 1024 * 1024 if youre the OS, * A MB on a floppy disk is 1000 * 1024 bytes, * A MB on a CD is 1024 * 1024 bytes. * A MB on a DVD is 1000 * 1000 bytes. * A MB/s on a bus means 1000 * 1000 bytes/s. You must admit that this context sensitive unit 'MB' is everything but clear with no less than three different interpretations. The difference between CDs and DVDs surprised me. I agree that it looks funny --- I always think of 'Men in Black' when I see 'MiB' somewhere :-) -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpm3pujSZ1JJ.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 15:50:20 (+0200), Martin Geisler wrote: Well, reading through the Usage Notes section on Wikipedia is interesting. We're dealing with bytes in all six cases, but there are differences: * A MB of RAM is 1024 * 1024 bytes. Agreed. * A MB on a harddisk is 1000 * 1000 bytes if you're the manufacturer, but 1024 * 1024 if youre the OS, Marketing ploys by manufacturers should not be allowed to redefine well-established nomenclature. * A MB on a floppy disk is 1000 * 1024 bytes, A 1440 floppy is correctly referred to as 1.4MB, not 1.44MB. Again...bad manufacturer. No cookie. * A MB on a CD is 1024 * 1024 bytes. Yup. * A MB on a DVD is 1000 * 1000 bytes. Same deal as a hard drive. It's a ploy. Just remember a standard DVD holds just under 4.5 GB. * A MB/s on a bus means 1000 * 1000 bytes/s. Ploy. You must admit that this context sensitive unit 'MB' is everything but clear with no less than three different interpretations. The only one of these that isn't well-defined and well-known is the bus speed example. If we allow learning curve to dictate our modus operandi, why aren't we all using MacOS and an iMac? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- Unix is like a Vorlon: It is incredibly powerful, gives terse, cryptic answers, and has a lot of things going on in the background. -- Jeff Dubrule --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 18:45:00 (+0200), FORT Yannick wrote: I really think the MiB standard MUST be used, if you don't respect standards, you surely want people to use .doc, .xls for office use, MSN as a chat protocol, THIS is stupid ... Your conclusion is not supported by your statements. You appear to be claiming that .doc and .xls are defiant of standards when, in reality, they are more standard than pretty much any other document format of their type. Even moreso as they move toward XML. When i read MiB, i'm sure it's 1024*1024 B, but when i read MB, i don't know if it's 1000*1000 or 1024*1024, f***ing unrespected standards Standards that are stupid should not be respected and should not be allowed to be called standards. When you read MB, you're dealing with 1024*1024 except when dealing with (1) manufacturer specs or (2) a stupid person. When you read MiB, you're dealing with (1) 1024*1024 and (2) someone who, like Microsoft, believes in catering to the lowest common denominator. I learn at school Kilo is 1000x and Mega is 1000*1000x, why would it be different for Bytes ? Because 2^10 is 1024, not 1000, and 2^20 is 1024*1024, not 1000*1000. Math is actually pretty simple, as it turns out. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- I have failed over and over again in my life. And that is why I succeed. -- Michael Jordan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Learning something in school in France does not make it a standard. And saying somebody MUST use something in HIS OWN program is just inappropriate. If you want a version with MiB, you can patch the sources :) On 7/21/05, FORT Yannick [EMAIL PROTECTED] wrote: Hello everyone; it's my first mail on this list ;) I really think the MiB standard MUST be used, if you don't respect standards, you surely want people to use .doc, .xls for office use, MSN as a chat protocol, THIS is stupid ... When i read MiB, i'm sure it's 1024*1024 B, but when i read MB, i don't know if it's 1000*1000 or 1024*1024, f***ing unrespected standards I learn at school Kilo is 1000x and Mega is 1000*1000x, why would it be different for Bytes ? Please use Kibi, Mebi Gibi, etc ... --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Michael Jennings [EMAIL PROTECTED] writes: If we allow learning curve to dictate our modus operandi, why aren't we all using MacOS and an iMac? :-) I guess it comes down to personal preferrence then... I like the idea of having prefixes with a fixed meaning: M = 10^6, Mi = 2^20, always. I just wanted to raise the issue in case the original author of the monitor hadn't thought of it yet. -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpHIEADKD5XB.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 19:00:11 (+0200), Martin Geisler wrote: I guess it comes down to personal preferrence then... I like the idea of having prefixes with a fixed meaning: M = 10^6, Mi = 2^20, always. If something more reasonable comes along, I might reconsider. But saying Kiba-Miba-Giba makes you sound like a drunken chimp with a lisp and an overbite. Try going into Best Buy or Fry's and asking for a spool of 700 Mibabyte CD-R's. Then tell me which is more confusing. :-) I'd also like to point out that it's 'k' and not 'K'. (And yes, it matters...see also pico and peta.) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- There's just something about debugging with a buggy debugger that reeks of rotten luck --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] mem leak in ewl
Hey, I've checked a small prog (a window, a box, a check button and a radio button) with valgrind. It remains 2 mem leak (for this prog ;) ) that i don't know how to fix. Here are the reports of valgrind: ==19838== 13 bytes in 1 blocks are definitely lost in loss record 9 of 93 ==19838==at 0x1B90259D: malloc (vg_replace_malloc.c:130) ==19838==by 0x1BBB773F: strdup (in /lib/tls/libc-2.3.3.so) ==19838==by 0x1B9DA6E8: ecore_config_string_get (ecore_config.c:170) ==19838==by 0x1B92120C: ewl_config_str_get (ewl_config.c:129) ==19838==by 0x1B921F0D: ewl_config_listener (ewl_config.c:434) ==19838==by 0x1B9DC008: ecore_config_listen (ecore_config.c:1210) ==19838==by 0x1B921D40: ewl_config_defaults_set (ewl_config.c:400) ==19838==by 0x1B921335: ewl_config_config_read (ewl_config.c:195) ==19838==by 0x1B9210DF: ewl_config_init (ewl_config.c:45) ==19838==by 0x1B92F374: ewl_init (ewl_misc.c:149) ==19838==by 0x8048897: main (test_button.c:18) ==19838== ==19838== ==19838== 1021 (56 direct, 965 indirect) bytes in 1 blocks are definitely lost in loss record 56 of 93 ==19838==at 0x1B90259D: malloc (vg_replace_malloc.c:130) ==19838==by 0x1B9DB1AC: ecore_config_typed_add (ecore_config.c:560) ==19838==by 0x1B9DB8CD: ecore_config_typed_default (ecore_config.c:900) ==19838==by 0x1B9DBB57: ecore_config_int_default (ecore_config.c:992) ==19838==by 0x1B921C3C: ewl_config_defaults_set (ewl_config.c:371) ==19838==by 0x1B921335: ewl_config_config_read (ewl_config.c:195) ==19838==by 0x1B9210DF: ewl_config_init (ewl_config.c:45) ==19838==by 0x1B92F374: ewl_init (ewl_misc.c:149) ==19838==by 0x8048897: main (test_button.c:18) maybe this can help. regards Vincent --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
I have a proposition: Why not make it a configurable option? That way everyone will be happy. yay!! Long live the freedom of choise! Daniel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: Ecore_Dlist_Append bug.
Thanks, patch applied to CVS.
On 7/21/05, Dylan Shell [EMAIL PROTECTED] wrote:
Currently ecore_dlist_append has a bug in that it increments the
list-nodes without considering whether it makes a previously invalid
list-index valid. If this happens, the list has a valid index, and thus
interprets the list-current member as pointing to node data.
Here is code that shows the invalid behavior in the current implementation:
= BEGIN CODE SNIPPET =
#include Ecore.h
#include Ecore_Data.h
#include string.h
#include stdlib.h
void print_list(Ecore_DList *list)
{
char *item;
/* Seek to end by looking for NULL */
ecore_dlist_goto_first(list);
while ((item = (char *)ecore_dlist_next(list)) != NULL)
{
printf(%p %s\n, item, item);
}
printf(\n);
}
int main(int argc, const char **argv)
{
char *first = first;
char *second = second;
char *p;
int i, nn;
Ecore_DList *list;
list = ecore_dlist_new();
ecore_dlist_append(list, first);
print_list(list);
ecore_dlist_append(list, second);
/* Now try another way: */
nn = ecore_dlist_nodes(list);
for (i = 0;i nn;i++)
{
p = ecore_dlist_goto_index(list, i);
printf(%d %p %s\n,i, p, p);
}
return EXIT_SUCCESS;
}
= END CODE SNIPPET =
One would expect the goto_index print list to print the list, instead
it prints the first element twice.
Below is the patch to CVS head that fixes this.
= BEGIN PATCH =
RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore/ecore_list.c,v
retrieving revision 1.15
diff -p -u -r1.15 ecore_list.c
--- ecore_list.c30 Jun 2005 16:47:29 -1.15
+++ ecore_list.c21 Jul 2005 18:22:30 -
@@ -372,6 +372,12 @@ static int _ecore_list_append_0(Ecore_Li
list-current = NULL;
}
+if (list-index = list-nodes) /* Index was out of bounds, ensure
that we don't make it in bounds
+ but with an invalid current
pointer by incrementing the nodes */
+list-index++;
+
+
+
list-nodes++;
return TRUE;
= END PATCH =
Dylan.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Please ignore the parent, WWW site issues for Eterm/SourceForge
On Wednesday, 20 July 2005, at 04:23:27 (-0600), Tres Melton wrote: Please ignore the parent email, I was collecting information for an email and accidently had the control down when I hit return. Sorry. Basically, go to http://sourceforge.net (login or not), search for Eterm, click on the Eterm project, click on the CVS link at the top of the page, and click on either the web based CVS viewer in Anonymous CVS Access (link below) or the Browse CVS Repository on the right and you go to a CVS viewer for the WWW site and not the Eterm project source (link below). The only way that I found the Eterm code was by going through the Enlightenment project. http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/Eterm/src/ Shouldn't one be able to get to Eterm's CVS source tree on SourceForge.net through the Eterm project page? If I've overlooked something then please tell me but I think this is wrong behavior. (TM) :-) I don't think there's a way to fix that, other than moving Eterm's CVS tree out of E's tree. And I don't really want to do that. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- [Heather Graham] is the new I-would-run-over-my-best-friend-in-a- hummer-to-get-next-to-her girl.-- Claude Nobler --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Proper programming environment
Hi, everyone. I was just wondering what sort of environment you guys program in so that when you edit, for example, some header file, you don't mess up the good one already on your system. Do you copy over all E17 stuff from /usr/include, /usr/local/include, etc. and /usr/lib, /usr/local/lib, etc. into a safe non-root folder? I'm asking for two reasons: I don't want to mess anything up and Evas events aren't being registered for some reason in a test program I made (so I'm thinking it's because ecore-config --cflags --libs outputs -I/usr/lib, so I should do gcc -I/home/me/workingfolder/lib instead)... Thanks for any suggestions! --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-Devel] Question about using system() inside a module
On Thu, 2005-07-21 at 17:30 -0700, Matthew Mullins wrote: Hello, I'm trying to come up with a better way to download (weather html in my case) than using wget through a system() function. Whenever system() is used, it hangs E completely until the function returns. For fast connections, or even if the network is completely down, you don't notice any pause. But if it times out trying to resolve the host name, or is on a really slow connection, it's not usable. So I'm looking for some better options. ecore_file_download dan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Please ignore the parent, WWW site issues for Eterm/SourceForge
On Thursday, 21 July 2005, at 19:34:58 (-0600), Eric Thompson wrote: I think that he's saying that the link to Eterm's cvs repository (as in the code repository) is pointing to the wrong place. It's pointing to the cvs repository for the content of the eterm.sourceforge.net website pages (html pages, imgs, etc). Which is the exact same thing that I get when I do exactly the same thing that Tres did. What the problem is is that the link needs to be pointing to the Eterm directory in E's tree, in http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/ rather than http://cvs.sourceforge.net/viewcvs.py/eterm/ Yes, I understand that. But that page is automatically generated by SourceForge. I can't change that link to point to E's CVS tree any more than I could point it to any other SF project tree. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- When I hear about people making vast fortunes without doing any productive work or contributing anything to society, my reaction is, 'How do I get in on that?'-- Dave Barry --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Wed, 20 Jul 2005 19:52:57 -0500 (CDT) Edward Presutti [EMAIL PROTECTED] wrote: Please disregard that first patch I sent out earlier. This one is an updated version. It has been tested against current anon-CVS as of 19:40 CST. This patch has configuration save/load as well as the features specified in patch 2.0. Here's the complete changelog for this patch. ADDED : Configuration Menus! ADDED : Support for Interval Changing. Intervals for CPU, Memory, and Network are all adjustable. ADDED : Support for Network Interface changing. Monitor now scans for network interfaces on load and provides a menu with a list. ADDED : Option to ignore Cache or Buffer memory. ADDED : Save/load functions for all new configuration options using e_config. (Thanks to the guys on the e-devel list for pointing me in the right direction) CHANGED : Clean up some more warnings. CHANGED : Moved configuration items to the correct structure. After reviewing the code of the modules provided with E17, this seemed like the more approriate place for them. TODO : The memory icon definitely needs some cleaning. The more I stare at it, the more I don't care for it. Thanks, -- Ed Presutti (ekrunch on freenode) Thanks a lot! That patch works nice. Correct memory output now with ignoring cached and buffered, configurable network interface... awesome! The only thing that would be neat would be the alignment, like having the monitors aligned vertically, not horizontal. And maybe deactivate one if preferred would be cool... but those are just ideas to make it more customizeable. Regards Tom pgpNKk7mwcSgy.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 10:33:00 +0200 gimpel [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005 19:52:57 -0500 (CDT) Edward Presutti [EMAIL PROTECTED] wrote: Please disregard that first patch I sent out earlier. This one is an updated version. It has been tested against current anon-CVS as of 19:40 CST. This patch has configuration save/load as well as the features specified in patch 2.0. Here's the complete changelog for this patch. ADDED : Configuration Menus! ADDED : Support for Interval Changing. Intervals for CPU, Memory, and Network are all adjustable. ADDED : Support for Network Interface changing. Monitor now scans for network interfaces on load and provides a menu with a list. ADDED : Option to ignore Cache or Buffer memory. ADDED : Save/load functions for all new configuration options using e_config. (Thanks to the guys on the e-devel list for pointing me in the right direction) CHANGED : Clean up some more warnings. CHANGED : Moved configuration items to the correct structure. After reviewing the code of the modules provided with E17, this seemed like the more approriate place for them. TODO : The memory icon definitely needs some cleaning. The more I stare at it, the more I don't care for it. Thanks, -- Ed Presutti (ekrunch on freenode) Thanks a lot! That patch works nice. Correct memory output now with ignoring cached and buffered, configurable network interface... awesome! The only thing that would be neat would be the alignment, like having the monitors aligned vertically, not horizontal. And maybe deactivate one if preferred would be cool... but those are just ideas to make it more customizeable. Regards Tom Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! pgp4x5dL5zpWf.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... if (bytes 1048576 ) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes 1024 bytes 1048576 ) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); edje_object_part_text_set(face-mem, mem-real-text, buf); } etc etc.. Now it gives me 190MB memory in use, which is correct, KB would have been a bit few, even it would be kewl, hehe Regards Tom pgpk9il07bwlH.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, July 21, 2005 3:42 am, gimpel said: On Thu, 21 Jul 2005 10:33:00 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! heh, oops. That's what I get for excessive copy/paste. I'm about to fly out for the day but i'll look into it later on. In reference to making it more modular... I agree! I'm looking into that for the next big patch. I'd really like to be able to enable/disable individual monitors, as well as add multiple copies of each monitor. (e.g. 2 network monitors for those of us w/ 2 nics.) Thanks for the input, I'm glad it's working for someone other than me! ;-) Ed --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
gimpel [EMAIL PROTECTED] writes: On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? I think it makes things clearer in the long run if we begin using these units. See http://physics.nist.gov/cuu/Units/binary.html and http://en.wikipedia.org/wiki/Binary_prefix for a bigger discussion. -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpMZw56bi1yT.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 04:27:51 -0600 Tres Melton [EMAIL PROTECTED] wrote: On Thu, 2005-07-21 at 11:07 +0200, gimpel wrote: On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... if (bytes 1048576 ) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes 1024 bytes 1048576 ) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); Regarding the above snippet: What if bytes == 1048576? It prints lots of bytes. The second part of the 'else if' is unnecessary since it will have short circuited on the 'if'. And most importantly, I have 2GB of ram and at the point where I'm using 1.801GB I don't want the thing to say 1GB or even (2GB) with better rounding, I want to know that I'm using 1827MB. The same thing applies when talking about KB although that will probably never show up. I propose that the quantity is kept in the lower units up through 4 digits and roll on the fifth. That will provide a much more accurate display. if (bytes = 1024) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes = 1) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); Just a thought, -- Tres Forwarded to the mailinglist! ;) The above was only a temporary fix to force it to show MB instead of KB. Not meant to be a real solution. if RAM 1GB is in use, it would simply (and ugly) round it up, right. Ed ^^ :) regards! tom pgpork0xx8uvo.pgp Description: PGP signature
