Re: [dwm] malloc'ed client in manage()
On Sun, 7 Sep 2008 11:25:53 +0200 Szabolcs Nagy [EMAIL PROTECTED] wrote: On 9/6/08, Filippo Erik Negroni [EMAIL PROTECTED] wrote: A preferable, safer and more portable way of achieving such initialisation is to use the compiler's static initialisation. is it because of null pointer might not be represented as zeros? I don't think so. KR, 2nd Ed. page 102: Pointers and integers are not interchangeable. Zero is the sole exception: the constant zero may be assigned to a pointer, and a pointer may be compared with the constant zero. The symbolic constant NULL is often used in place of zero, as a mnemonic to indicate that this is a special value for a pointer I think it's quite explicit: the NULL macro expands to 0. -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: [dwm] malloc'ed client in manage()
On Sun, 7 Sep 2008 13:53:11 +0200
Szabolcs Nagy [EMAIL PROTECTED] wrote:
On 9/7/08, Nicolas Martyanoff [EMAIL PROTECTED] wrote:
I think it's quite explicit: the NULL macro expands to 0.
NULL macro does not necessaryly expands to 0, but this is basic
knowledge look it up in the standard.
what am i concerned about is the internal null pointer representation
(which has nothing to do wether NULL is defined 0 or not)
NULL is a macro that expands to the
implementation-defined null pointer constant. [7.17.3]
If NULL expands to 0, then basic logic tells me that the null pointer
constant is 0; if I'm making a logic error, what is it ?
it is explicitely stated in c99 that there might be architectures
where memset(p, 0, sizeof(p)) is not equivalent to p=0;
The standard contains ambiguities, everybody knows that; if KR 2 tells
NULL expands to 0, and the C standard tells that NULL expands to the
null pointer constant, then I think we can assume that setting a pointer
to 0 is ok.
Therefore:
struct foo {
int i;
void *ptr;
}
struct foo bar;
memset(bar, 0, sizeof(struct foo));
Will get bar.i == 0, and foo.ptr == NULL.
Now, another idea is to find an existing architecture where the null
pointer representation is NOT 0. To be honest, if such an architecture
exists, then a lot of softwares won't work on it. (and KR 2 will be
wrong...)
--
Nicolas Martyanoff
http://codemore.org
[EMAIL PROTECTED]
signature.asc
Description: PGP signature
Re: [dwm] xinerama, things get more and more useful
On Thu, 28 Feb 2008 23:01:39 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: There are kind a lot of caveats in current hg tip, but I encourage early adaptors to give it a try and to update from time to time, and to report bugs. The worst caveat atm is that the focus handling among different views (screens) might need mouse assistance in some cases, so I'm aware of this already. http://www.suckless.org/shots/dwm-xinerama-new.png Kind regards, I just tried the last hg version, and I am a bit disappointed. The idea to divide up the tags between the screens isn't really ergonomic. A dual (or more) screen, is particulary useful to have two or more applications on a single view, for example a coding window and a pdf research paper. With the new system, navigating between the tags is really tedious; with wmii, I knew that my coding windows (editor, doc...) were on tag '2'. A simple alt-2 and it was restaured. With dwm old xinerama system, I had to press alt-2 foreach screen which was ok though less practical. Now I have to remember two tag, on per screen, for each couple of application. The only advantage of this system is to remove the need to manually toggle between the screens. Furthermore, if it was possible before to use a window covering the whole display (blender for example) by switching to float mode, the by enabling the same tag on each screen (yes it was painful), it's not possible anymore. I really hope this is gonna change :( Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] xinerama, things get more and more useful
On Sat, 1 Mar 2008 05:33:03 -0500 hiro [EMAIL PROTECTED] wrote: I just tried the last hg version, and I am a bit disappointed. The idea to divide up the tags between the screens isn't really ergonomic. A dual (or more) screen, is particulary useful to have two or more applications on a single view, for example a coding window and a pdf research paper. With the new system, navigating between the tags is really tedious; with wmii, I knew that my coding windows (editor, doc...) were on tag '2'. A simple alt-2 and it was restaured. With dwm old xinerama system, I had to press alt-2 foreach screen which was ok though less practical. Now I have to remember two tag, on per screen, for each couple of application. The only advantage of this system is to remove the need to manually toggle between the screens. Furthermore, if it was possible before to use a window covering the whole display (blender for example) by switching to float mode, the by enabling the same tag on each screen (yes it was painful), it's not possible anymore. I really hope this is gonna change :( Regards, Try xmonad, it's usable for the things i'm doing I personnally have nothing against xmonad, but I have years of experience in C programming, none in haskell, and I like to be able to tweak my wm; I think I'm gonna write my own wm :/ -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] Xinerama and multihead support
On Tue, 12 Feb 2008 11:19:52 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: Hi there, more and more I get straight to a 4.8 release. The hg tip is still experimental, but Xinerama works for me already: http://www.suckless.org/shots/dwm-xinerama.png Kind regards, Excellent new ! I just installed the mercurial version on my desktop, and it works pretty well. The display has two 20 monitors in 1400x1050 managed by NVidia's TwinView. A small problem found: dwm crashed with an X error (request code=54, error code=4, BadPixmap with X_FreePixmap) when I do this: - Open Firefox with dmenu (last mercurial version) in the left screen. - Open an Xterm with alt+enter. - Run xrandr in the term. - Exit the term with 'exit'. Hope it will help. Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] Xinerama and multihead support
On Tue, 12 Feb 2008 11:19:52 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: Hi there, more and more I get straight to a 4.8 release. The hg tip is still experimental, but Xinerama works for me already: http://www.suckless.org/shots/dwm-xinerama.png Kind regards, After other tests, it seems the bug occurs when you launch xrandr, it seems to be the minimal condition. Other remark; I enjoy the screen system (one application per screen), but this isn't suitable at all for some applications, such as blender, which are a lot more confortable on my full display (2800x1050). Is there a way to tell dwm to let some applications use the full display, and not only the current screen ? Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] Xinerama and multihead support
On Tue, 12 Feb 2008 23:08:51 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: Other remark; I enjoy the screen system (one application per screen), but this isn't suitable at all for some applications, such as blender, which are a lot more confortable on my full display (2800x1050). Is there a way to tell dwm to let some applications use the full display, and not only the current screen ? I'm not totally sure about all design goals yet. Let's postpone the discussion after the 4.8 release, ok? Kind regards, As you wish :) It was nothing but a simple info, since without that, all people who use multihead for some large application won't be able to use dwm. Let's wait 4.8 ! Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] Xinerama and multihead support
On Tue, 12 Feb 2008 11:19:52 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: Hi there, more and more I get straight to a 4.8 release. The hg tip is still experimental, but Xinerama works for me already: http://www.suckless.org/shots/dwm-xinerama.png Kind regards, Ouups, retested, and the bugs raises just when I run xrandr, so no need to exit the term. Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] [ANNOUNCE] dvtm-0.4
On Wed, 6 Feb 2008 15:37:07 -0500 Ritesh Kumar [EMAIL PROTECTED] wrote: * implement a command mode (i am not yet sure about this one) * scrollback history support (this is a low priority item for me) Apart from that i consider dvtm feature complete. Really nice work Marc. I welcome all the changes in dvtm 0.4. Also, I now think that the ctrl g + num shortcut is much more convenient than the command mode idea I had proposed... so may be you can strike that item off the TODO list all together :) _r As a big vim fan, I'd like to have a small command mode for basic operations, such as select a window (ctrl-g :numberofthewindow) or kill a window (ctrl-g :k numberofthewindow). I find it is easier to remember these commands than to learn a new set of keyboard accelerators (I've already to cope with those of dwm, screen, and vim). Am I the only one to like the vim-way ? :) -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] [ANNOUNCE] dvtm-0.2
On Sun, 30 Dec 2007 14:02:59 +0100 Marc Andre Tanner [EMAIL PROTECTED] wrote: esting. Could you please send me the value of $LANG and the output of locale? It would also be useful if you could run the following 2 lines once within dvtm and once in uxterm. $ echo $LANG en_US.utf8 $ locale LANG=en_US.utf8 LC_CTYPE=en_US.utf8 LC_NUMERIC=en_US.utf8 LC_TIME=en_US.utf8 LC_COLLATE=C LC_MONETARY=en_US.utf8 LC_MESSAGES=en_US.utf8 LC_PAPER=en_US.utf8 LC_NAME=en_US.utf8 LC_ADDRESS=en_US.utf8 LC_TELEPHONE=en_US.utf8 LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=en_US.utf8 LC_ALL= perl -C -e 'print pack(U,0x20ac).\n' perl -C -e 'print pack(U,0x00e9).\n' The first one should print an euro sign, second your é. In a simple xterm: $ perl -C -e 'print pack(U,0x20ac).\n' € $ perl -C -e 'print pack(U,0x00e9).\n' é In dvtm, in the two cases, I get a blank character. Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
Re: [dwm] [ANNOUNCE] dvtm-0.2
On Sun, 30 Dec 2007 23:08:00 +0100 Marc Andre Tanner [EMAIL PROTECTED] wrote: On Sun, Dec 30, 2007 at 10:07:00PM +0100, Nicolas Martyanoff wrote: On Sun, 30 Dec 2007 14:02:59 +0100 Marc Andre Tanner [EMAIL PROTECTED] wrote: esting. Could you please send me the value of $LANG and the output of locale? It would also be useful if you could run the following 2 lines once within dvtm and once in uxterm. $ echo $LANG en_US.utf8 Ok could you please try the following and see whether it works: export LANG=en_US.UTF-8 dvtm if this works then i will make an appropriate patch. Regards, Marc With this, it works perfectly. Regards, -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED]
