[dev] [surf] Segfault bug
Hi, For a while I've been frustrated when I close a surf window, it takes down the process that created it, along with all windows of that process. For clicking a link in gmail will open a new window, and closing that window sometimes closes the parent window as well. Today I had some time to insert printfs into surf.c to find out what's going on. It turns out that closing a window while it is loading causes a segfault, and so all the 'struct Clients' of that process die. This is somewhat okay if it the process just had one window, but sucks otherwise. This also might be why from time to time I have to rm my cookies file to make gmail/gchat will work, because segfaults skips the cleanup() process? I'm using a key sequence bound to the killclient() function in dwm-5.5. I'm using the latest pull of surf (220:e83fbd17d63a). Thanks
Re: [dev] [surf] Segfault bug
I just tried opening a link in a new window, and the segfault still happens. It would be nice if a new window was opened in a different instance of surf, but I have the vague impression that in some cases windows for the same site sometimes need to communicate. For example a site opens a window for Search. It displays the search bar and result snippets there, but actual result pages open in the original window. On Wed, Jun 9, 2010 at 9:28 PM, Rob wrote: >> For a while I've been frustrated when I close a surf window, it takes >> down the process that created it, along with all windows of that >> process. For clicking a link in gmail will open a new window, and >> closing that window sometimes closes the parent window as well. Today >> I had some time to insert printfs into surf.c to find out what's going >> on. > > I've been having this bug too, but I think (if i remember correctly), > that it only happens if I middle > click links which invokes the javascript new window() business. I > think when I use the right click > menu's Open In New Window option it doesn't cause the segfault > (because it spawns a new surf > instance?). I'll check when I'm next at my machine. > >> It turns out that closing a window while it is loading causes a >> segfault, and so all the 'struct Clients' of that process die. This >> is somewhat okay if it the process just had one window, but sucks >> otherwise. > Could the javascript in script.js be altered to spawn a new surf > instance (perhaps > via javascript callbacks or however surf has them set up?) instead of > a new window > with the same surf instance? Kind of defeats the whole one-task-one-process > aim > of surf. > >> I'm using a key sequence bound to the killclient() function in dwm-5.5. >> I'm using the latest pull of surf (220:e83fbd17d63a). > I'm also using the latest pull. > >
Re: [dev] [surf] Segfault bug
On Wed, Jun 9, 2010 at 10:01 PM, Kris Maglione wrote: > On Wed, Jun 09, 2010 at 12:50:06PM -0700, Gene Auyeung wrote: >> >> Hi, >> >> For a while I've been frustrated when I close a surf window, it takes >> down the process that created it, along with all windows of that >> process. For clicking a link in gmail will open a new window, and >> closing that window sometimes closes the parent window as well. Today >> I had some time to insert printfs into surf.c to find out what's going >> on. > > Why don't you just use gdb (apart from the fact that surf doesn't build with > debugging information by default)? > Apart from not knowing how to use gdb beyond the basics, surf's code is clean/simple enough that printing debug statements work. But yes, good suggestion. > -- > Kris Maglione > > Every program has (at least) two purposes: the one for which it was > written, and another for which it wasn't. > --Alan J. Perlis > > >
Re: [dev] dmenu: state of the tip
Hi, a small typo in dmenu.c. 533s/i++/++i
--- dmenu.c 2010-08-03 10:06:53.083866866 -0700
+++ bugfix.c2010-08-03 10:06:19.600536452 -0700
@@ -530,7 +530,7 @@ main(int argc, char *argv[]) {
else if(!strcmp(argv[i], "-p"))
prompt = argv[++i];
else if(!strcmp(argv[i], "-fn"))
- initfont(dc, argv[i++]);
+ initfont(dc, argv[++i]);
else if(!strcmp(argv[i], "-nb"))
normbgcolor = argv[++i];
else if(!strcmp(argv[i], "-nf"))
-Gene
On Mon, Aug 2, 2010 at 7:02 AM, Connor Lane Smith wrote:
> As of my latest commit dmenu tip is a third smaller than 4.1.1,
> because of both libdraw and my zealous hammering of the 'd' key. But
> while restructuring I may have overlooked some subtlety and broken
> something, so before we consider releasing 4.2 I'd like to have a
> little bug hunt. If anyone can find any bugs in dmenu tip could they
> please tell me? Thanks.
>
> Also, does anyone have any ideas about how dwm could automatically
> spawn dmenu with the '-b' flag when !topbar? At the moment you have to
> add it to dmenucmd by hand, which is okay but not great. It could work
> if topbar were a macro, but that may seem odd amongst consts.
>
> Thanks,
> cls
>
>
Re: [dev] Re: dmenu: state of the tip
Hi, I'm using '-Misc-Fixed-Medium-R-Normal--8-80-75-75-C-50-ISO10646-1' and non ascii characters do show up correctly in dmenu (I visited some sites that has non ascii characters in their titles eg http://www.google.ru/intl/ru/ads/ and http://www.google.com.hk/intl/zh-TW/ads/ads_2.html etc) I also am using two monitors with dwm tip. dmenu works correctly on both monitors.. but I'm not sure how to further test this. Thanks, Gene On Tue, Aug 10, 2010 at 9:44 AM, Connor Lane Smith wrote: > > Hey, > > Is there anyone with either a multi-screen Xinerama setup or a font > with proper UTF8 characters, who can confirm whether those two > features work in dmenu tip? My machine has neither, so when editing > those features I'm sort of coding blind. If someone could test to make > sure they work properly I would be very grateful. Providing they do, > 4.2 should be just around the corner. > > Thanks, > cls >
Re: [dev] [surf] URI handling, with patch
I've been using a patched version of dmenu since I started using surf. It sort of emulates firefox's address bar, (but I haven't been using firefox in a while so I'm not too sure..): 1) The Tab key acts as the Down key and Shift+Tab acts as Up. 2) Before Tab/Down/Shift+Tab/Up keys are pressed, no item is selected, regardless of if any items are matched or not. 3) Selecting an item doesn't cause dmenu to match, editing the char *text buffer does. 4) Selecting an item, though, fills the text buffer with the selected item. 5) When Return is pressed, whatever is in the text buffer will be outputted. So if I just want to input something, I'll type it and hit Return. If I want to input something similar to what dmenu matched, I'll type it, complete it by pressing Down or Tab, then backspace or Ctrl+w to edit, then I hit Return. Obviously if I want to input something that dmenu matched, I'll type enough so that the item is just a couple Tabs away, select it then hit Return. Attached is the patch that's really ugly, it was nicer before but dmenu tip's been going through some changes (thanks to cls) and I just wanted to make my patch work for now. If anyone's interested I can maintain one on the wiki. -Gene On Wed, Aug 18, 2010 at 4:56 AM, anonymous wrote: > On Tue, Aug 17, 2010 at 06:52:40PM -0400, Ryan Mullen wrote: >> Second, dmenu's "suggested" integration with surf is a bit dodgy. If, >> for example, a user is viewing surf.suckless.org and they wish to >> navigate to suckless.org, they would be required to strike >> shift+return in order to actually visit suckless.org. If the shift key >> is not used, the current page will simply refresh. The reason for the >> refresh is because dmenu matches the input text against the selected >> text, and if it is a substring of the selected text, it will just >> output the selected text when return has been struck, which means the >> page simply refreshes because the new URI is the same as the current >> one. > >> As far as I know, the dmenu problem is a feature for one set of users >> and an issue for another set. I wouldn't know how to please everyone >> on this. Feedback appreciated. > > Maybe just make return act like shift-return and remove shift-return? > So dmenu will act like shell with tab-completion. > > > tab_to_select.patch Description: Binary data
Re: [dev] Remount rootfs sync on impending battery depletion.
Hi,
Just curious, how would the script get permission to mount? You can't
type the password for sudo because it's not interactive. And you can't
rely on the limited time that sudo grants access if you run the script
with sudo, because presumably the battery lasts much longer than that?
Thanks,
Gene
On Sat, Dec 4, 2010 at 11:16 AM, Antoni Grzymala wrote:
> Hi,
>
> just wanted to share a simple idea here – a little feature implemented
> in my statusbar script: remount the rootfs sync, when the battery
> level is below some predefined threshold and falling.
>
> I somehow find it less distracting than warnings popping up and less
> annoying then a forced poweroff upon reaching some level.
>
> Here's my implementation (full of bash, gnu tools and other stuff you
> love), feel free to pick ideas if you find any of it useful:
>
> #!/bin/bash
>
> while test 1; do
>
>
> # Battery charge.
>
> DO_BATTERY=""
> BATTERY=BAT0 ### <- Battery ID
>
> grep ' charged' /proc/acpi/battery/${BATTERY}/state 2>&1 >/dev/null &&
> TIME_LEFT="" || DO_BATTERY=1
>
> if [[ -n ${DO_BATTERY} ]]; then
> TIME_LEFT=`acpi | head -n1 | sed -r \
> 's/^.*Battery//; s/discharging, /-/i; s/charging, /+/i; s/,//g; s/
> ([0-9][0-9]:[0-9][0-9]):[0-9][0-9] .*$/ \1 /'`
>
> if [[ "${TIME_LEFT}" =~ ^-[0-5]% ]]; then
> TIME_LEFT="[fs SYNC] ${TIME_LEFT}"
> grep '^/dev/root.*sync,' /proc/mounts || sudo mount / -o remount -o sync
> else
> grep '^/dev/root.*sync,' /proc/mounts && sudo mount / -o remount
> fi
>
> TIME_LEFT="${TIME_LEFT} · "
> fi
>
> ### [...much other code including some sleep...]
>
> STATUS="${TKABBER}${UNREADMAIL}${TIME_LEFT}${PPPD}${WIRELESS}${FETCHMAIL}${UPTIME}${DATE}"
> xsetroot -name "${STATUS}"
>
> done
>
> --
> [a]
>
>
Re: [dev] Remount rootfs sync on impending battery depletion.
On Sat, Dec 4, 2010 at 11:29 AM, Antoni Grzymala wrote: > Simplest way: > > ALL=(ALL) NOPASSWD: ALL > > The safer way would obviously be if you limit this to /bin/mount. Ah yes I forgot about that. It's more configuration, but I guess there's no getting around that. Thanks, Gene
Re: [dev] [dwm] floating window if fullscreen
On Mon, Jan 24, 2011 at 5:53 PM, Jan wrote: > Since your new to dwm I'd like to point you to the bstack layouts you can > find in the wiki. In my eyes they work very nice with netbooks. I don't have a netbook or even a widescreen. So I was just wondering why further reducing an already small vertical screen space is good? -Gene
