Re: [dev] [wmii] notifications only work from tag 1
On 2010-01-14, Yuval Hager wrote: > I am trying to send notifications using 'notify-send' (libnotify) and I > found out they work only if they are sent from tag 1. > otherwise, I get the following message from dbus-daemon: > > , > | (:5963): Wnck-WARNING **: Someone set a weird number of desktops > in _NET_NUMBER_OF_DESKTOPS, assuming the value is 1 > | > | > | Wnck-CRITICAL **: wnck_window_is_on_workspace: assertion > `WNCK_IS_WORKSPACE (workspace)' failed > | aborting... > ` > > Anyone has a clue? Yes, this seems to be a bug. I'm surprised that libnotify chokes (or even cares), though. Fixed as of 2600:5973799cd90a.
Re: [dev] [wmii] sticky tagrule
On 2009-12-31, Noah Tye wrote: > I run trayer, a small system tray, so that I can run nm-applet and use > Gnome's volume applet. Trayer is automatically started via my wmiirc, > however, it is not visible on all views (it's not sticky). > > I want trayer to be sticky. This is possible[1] via: > > wmiir xwrite /client/$client/tags /./ > > However, I want trayer to be sticky without my having to type that > command manually. This seems to be something I'd do through tagrules, > but this doesn't work: > > wmiir write /tagrules < /trayer/ -> /./ > /MPlayer|VLC/ -> ~ > ! > > If I write 't' instead of '/./', trayer gets put on a view named 't', > so the problem is not in selecting the right client. Sorry, I've been away. This has been fixed in mercurial. I suggest using wihack rather than tag rules, though: wihack -tags /./ trayer ...
Re: [dev] wmii in virtualbox won't resize when display is resized
On 2010-01-24, Andreas Wagner wrote: > I am running linux in virtualbox and I have switched from stumpwm to wmii. I > have a problem I did not have when using stumpwm, this leads me to believe > the problem may be a wmii problem not a virtualbox problem. When I resize > the Virtualbox display window under wmii the X display does not resize. This > may be a bug, I'm not sure, but any help (or fix!) would be appreciated. I've never managed to get VirtualBox working, so I'm not really clear on your problem. Can you describe the problem in some more detail? Screenshots would also be helpful.
[dev] wmii in virtualbox won't resize when display is resized
Hello wmii devs, I am running linux in virtualbox and I have switched from stumpwm to wmii. I have a problem I did not have when using stumpwm, this leads me to believe the problem may be a wmii problem not a virtualbox problem. When I resize the Virtualbox display window under wmii the X display does not resize. This may be a bug, I'm not sure, but any help (or fix!) would be appreciated. Thanks, Andreas
[dev] [OFFTOPIC] Recommended meta-build system
Hi, I'm wondering if anyone has had particularly good experiences with any meta-build system (cmake, etc) in the following circumstances: I will have a large codebase which consists of some generic files and some processor specific files. (I'm not worried about OS environent stuff like "has vsnprintf?" that configure deals with.) In addition, it'd be nice to be able to have options like "debugging", "release", "grof-compiled", etc, similar to procesor specification. I need to be able to select the appropriate files for a given build and compile them together to form an executable. It would be preferrable if all object files and executables could coexist (because it's a C++ template heavy source-base that means individual files compile relatively slowly, so it'dbe preferrable only to recompile if the source has actually changed) using directories or naming conventions. I've been doing some reading about things like cmake and SCons but most strike me as having "built-in logic for their normal way of doing things and are relatively clunky if you specify something different". (Incidentally, when I say meta-build system I mean that I don't mind if it builds things directly or if it outputs makefiles that can be invoked.) Does anyone have any experiences of using any tool for this kind of purpose? (One option would be to just have a static makefile and then do some include-path hackery to select processor specific directories to pick a specific versions of files depending on options and then rely on ccache to pick up the correct object file from the cache rather than recompiling. But that feels like a hack for avoiding having a more expressive build system.) Many thanks for sharing any experiences, -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] [OFFTOPIC] How to know the size of a process?
On Sun 24 Jan 2010 at 13:48:08 PST Charlie Kester wrote: On Sun 24 Jan 2010 at 13:26:56 PST Premysl Hruby wrote: On (24/01/10 13:07), Charlie Kester wrote: Date: Sun, 24 Jan 2010 13:07:14 -0800 From: Charlie Kester To: dev@suckless.org Subject: Re: [dev] [OFFTOPIC] How to know the size of a process? List-Id: dev mail list X-Mailer: Mutt 1.5.20 User-Agent: Mutt/1.5.20 (2009-06-14) On Sun 24 Jan 2010 at 09:42:59 PST Premysl Hruby wrote: Shared libraries are not the only shared memory, look for example at dabases (postgres etc) which use enormous blocks of shared memory. Also, you can't simply ignore the shared memory even in case of library, that would highly underestimate your metering. Good point. However, on second thought, it doesn't really undercut what I was saying about things that are called "shared" but really aren't. If you collect samples of typical system load before and during the program run, you can use the difference as a fairly reliable estimate of the additional load the program puts on the system. If the shared libraries, shared memory or databases really are shared, they'll already be part of the system load prior to the program run, and can be treated as if they were part of the OS. On the other hand, if they aren't already in that typical pre-program load, I think you'd be justified in counting them as part of the overall program size. I think this would be true even if you occasionally run some other programs that use the same stuff. If you never run those other programs simultaneously with this one, it doesn't matter to the load calculation that they "share" anything with it. If the point of the original question wasn't to determine the additional load caused by a given program, then it would seem to be a merely academic exercise.
Re: [dev] saving program options
> TAOUP also recommends small programs that do just one thing. If you > have so many options that you need a "huge structure" to store them, > that might be a sign that your program is overly complex. Consider > factoring it into a set of smaller cooperating processes. It is not too big, but there are more than 7 options anyway. What about troff, for example? It is not very small and has more than 7 options.
[dev] saving program options
Well said. > TAOUP also recommends small programs that do just one thing. If you > have so many options that you need a "huge structure" to store them, > that might be a sign that your program is overly complex. Consider > factoring it into a set of smaller cooperating processes. > > Many people have become accustomed to thinking in terms of large, > monolithic applications. This leads them to think of modularity as > something that only applies to the functions within that kind of > application. > Instead, think of the *shell* as the main program and your set of small > utilities as the modules. The classic Unix utility designed to do one > thing and do it well is the paradigm example of what we mean by > coherence. The operating system enforces encapsulation. When the > modules communicate with each other using text streams over stdin and > stdout, or using sockets and text-based protocols like those described > in TAOUP, then they will be loosely coupled. These are the virtues > which are usually associated with good "modularity". > > Take those rules of thumb like the ones you cite above and apply them to > the programs themselves. A program that takes a lot of options is like > a function that takes a lot of arguments. > > >
Re: [dev] saving program options
On Sun 24 Jan 2010 at 11:57:34 PST anonymous wrote: Where programs should store their options? Sometimes it is said that global variables are bad, but what is better? Some huge structure storing all options? Of course, they can be divided into many structures or they can be passed on a stack instead of passing pointer to structure but it is not effective. Here is citation from TAOUP (http://www.catb.org/esr/writings/taoup/html/ch04s06.html): " Here are some questions to ask about any code you work on that might help you improve its modularity: * How many global variables does it have? Global variables are modularity poison, an easy way for components to leak information to each other in careless and promiscuous ways. * Do any of your APIs have more than seven entry points? Do any of your classes have more than seven methods each? Do your data structures have more than seven members? " So lots of global variables are bad, but saving them in a local structure is bad too? Is there any other other solution? TAOUP also recommends small programs that do just one thing. If you have so many options that you need a "huge structure" to store them, that might be a sign that your program is overly complex. Consider factoring it into a set of smaller cooperating processes. Many people have become accustomed to thinking in terms of large, monolithic applications. This leads them to think of modularity as something that only applies to the functions within that kind of application. Instead, think of the *shell* as the main program and your set of small utilities as the modules. The classic Unix utility designed to do one thing and do it well is the paradigm example of what we mean by coherence. The operating system enforces encapsulation. When the modules communicate with each other using text streams over stdin and stdout, or using sockets and text-based protocols like those described in TAOUP, then they will be loosely coupled. These are the virtues which are usually associated with good "modularity". Take those rules of thumb like the ones you cite above and apply them to the programs themselves. A program that takes a lot of options is like a function that takes a lot of arguments.
Re: [dev] [OFFTOPIC] How to know the size of a process?
On Sun 24 Jan 2010 at 13:26:56 PST Premysl Hruby wrote: On (24/01/10 13:07), Charlie Kester wrote: Date: Sun, 24 Jan 2010 13:07:14 -0800 From: Charlie Kester To: dev@suckless.org Subject: Re: [dev] [OFFTOPIC] How to know the size of a process? List-Id: dev mail list X-Mailer: Mutt 1.5.20 User-Agent: Mutt/1.5.20 (2009-06-14) On Sun 24 Jan 2010 at 09:42:59 PST Premysl Hruby wrote: Shared libraries are not the only shared memory, look for example at dabases (postgres etc) which use enormous blocks of shared memory. Also, you can't simply ignore the shared memory even in case of library, that would highly underestimate your metering. Good point.
Re: [dev] [OFFTOPIC] How to know the size of a process?
On (24/01/10 13:07), Charlie Kester wrote: > Date: Sun, 24 Jan 2010 13:07:14 -0800 > From: Charlie Kester > To: dev@suckless.org > Subject: Re: [dev] [OFFTOPIC] How to know the size of a process? > List-Id: dev mail list > X-Mailer: Mutt 1.5.20 > User-Agent: Mutt/1.5.20 (2009-06-14) > > On Sun 24 Jan 2010 at 09:42:59 PST Premysl Hruby wrote: > > > >Btw, There's one issue with trying to get size of process -- shared > >memory. To which process should it count? And how? Or count only > >fraction for each of process using that shared memory ... Not easy. :-) > > If the shared library really is shared -- i.e., used by two or more > programs that you are actually running -- then you can treat it as if it > were part of the operating system. > > But in practice many so-called shared libraries aren't actually shared. > If you never run more than one program that uses it, then you should > count the library as part of that program. > > Many of the shared libraries circulating in the open source world are > what I call vanity libraries. Their authors would like to think they're > getting more widespread use, but in truth no one uses them but > themselves. > Shared libraries are not the only shared memory, look for example at dabases (postgres etc) which use enormous blocks of shared memory. Also, you can't simply ignore the shared memory even in case of library, that would highly underestimate your metering. -Ph -- Premysl "Anydot" Hruby, https://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dev] [OFFTOPIC] How to know the size of a process?
On Sun 24 Jan 2010 at 09:42:59 PST Premysl Hruby wrote: Btw, There's one issue with trying to get size of process -- shared memory. To which process should it count? And how? Or count only fraction for each of process using that shared memory ... Not easy. :-) If the shared library really is shared -- i.e., used by two or more programs that you are actually running -- then you can treat it as if it were part of the operating system. But in practice many so-called shared libraries aren't actually shared. If you never run more than one program that uses it, then you should count the library as part of that program. Many of the shared libraries circulating in the open source world are what I call vanity libraries. Their authors would like to think they're getting more widespread use, but in truth no one uses them but themselves.
[dev] saving program options
Where programs should store their options? Sometimes it is said that global variables are bad, but what is better? Some huge structure storing all options? Of course, they can be divided into many structures or they can be passed on a stack instead of passing pointer to structure but it is not effective. Here is citation from TAOUP (http://www.catb.org/esr/writings/taoup/html/ch04s06.html): " Here are some questions to ask about any code you work on that might help you improve its modularity: * How many global variables does it have? Global variables are modularity poison, an easy way for components to leak information to each other in careless and promiscuous ways. * Do any of your APIs have more than seven entry points? Do any of your classes have more than seven methods each? Do your data structures have more than seven members? " So lots of global variables are bad, but saving them in a local structure is bad too? Is there any other other solution?
Re: [dev] [OFFTOPIC] How to know the size of a process?
> On (24/01/10 18:35), pmarin wrote: > > Hi all. > > Anyone know how to know the size (kb) of a process in Linux? > > using the proc filesystem I can know the number of pages that it uses > > (/proc/pid/statm). How I can convert > > it to kb? Any posix way? Here's some funny script [1] I'm aware of, provides a nice lookup table if you really care about these things. Not really sure if you can rely on it, every program I run gives different values when talking about ram (htop, free, this ps_mem). Regards, Ted [1] http://www.pixelbeat.org/scripts/ps_mem.py
Re: [dev] [OFFTOPIC] How to know the size of a process?
pmarin dixit (2010-01-24, 18:35): > Hi all. > Anyone know how to know the size (kb) of a process in Linux? > using the proc filesystem I can know the number of pages that it uses > (/proc/pid/statm). How I can convert > it to kb? Any posix way? Man proc(5). The sizes given are in pages. The rest: http://tinyurl.com/yhfqna5 -- [a]
Re: [dev] [OFFTOPIC] How to know the size of a process?
On (24/01/10 18:35), pmarin wrote: > Date: Sun, 24 Jan 2010 18:35:31 +0100 > From: pmarin > To: dev@suckless.org > Subject: [dev] [OFFTOPIC] How to know the size of a process? > List-Id: dev mail list > > Hi all. > Anyone know how to know the size (kb) of a process in Linux? > using the proc filesystem I can know the number of pages that it uses > (/proc/pid/statm). How I can convert > it to kb? Any posix way? > > pmarin > You can get size of page very easily, man sysconf and search for PAGESIZE. Btw, There's one issue with trying to get size of process -- shared memory. To which process should it count? And how? Or count only fraction for each of process using that shared memory ... Not easy. :-) -Ph -- Premysl "Anydot" Hruby, https://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
[dev] [OFFTOPIC] How to know the size of a process?
Hi all. Anyone know how to know the size (kb) of a process in Linux? using the proc filesystem I can know the number of pages that it uses (/proc/pid/statm). How I can convert it to kb? Any posix way? pmarin
