Re: [dev] unsubscribe
Chill dude On 7/20/10 15:01 , Val Polyakov wrote: Excuse me for living and forgetting to append +unsubscribe Fsck off... People never learn... - Original message -
Re: [dev] [surf] segfault
Cannot reproduce, sorry. Works over here
Re: [dev] goblin (9base in Go)
How about improving the flags-package - or somewhat merging optparse into flags (keeping the interface backwards-compatble). I assume that would be greatly appreciated. Surma On Mon, Mar 29, 2010 at 5:51 PM, Jeff Shipley wrote: > On Mon, Mar 29, 2010 at 2:41 AM, Szabolcs Nagy wrote: >> On 3/29/10, Jeff Shipley wrote: >>> If you feel like criticizing, suggesting improvements, or helping out, >>> check it out at http://bitbucket.org/amertune/goblin >>> >>> >> >> grep.go:7: fatal error: can't find import: optparse >> i think you should use the "flag" package there as well >> >> in cat i think (&buf)[0:n] is the same as buf[0:n] >> >> the underscore_naming_style does not look nice in go somehow >> >> > > The Makefile isn't quite right for grep. It expects to find a compiled > optparse in the _obj directory. > > The primary reason I went with the optparse library instead of using > flag is that flag doesn't support multiple values for the same flag. > grep -e expression1 -e expression2 -e expression3 > would be completely broken when using the flag package. I know that > it's not really necessary; -e '(expression1|expression2|expression3)' > would do the exact same thing. Still, it's a feature of grep that I > like, and not one that I'd want to drop just because the built-in > package doesn't support it. > > The biggest thing I don't like about using optparse for grep (and flag > for everything else) is that it breaks consistency with the other > programs. grep can group options (-hnv), while none of the other > programs can. I'm considering moving everything over to optparse, for > consistency. > > Thanks for the language tips, I just started learning Go last week > when I started this project. > >
[dev] [surf] GZip compression
Hi, I don't want this in the sunday-release, or anything, I just noticed, that gzip-compressed pages are not supported (e.g. http://www.lenovo.de) Is that a surf or a webkit issue?! Fixable? Surma
Re: [dev] terminal that accepts any size
I can't speak for wmii, but if you make dwm ignore resizehints xterm behaves exactly like that. If you insist on keeping resizehints enabled, I don't believe you'll find a terminal which works like that out of the box. Suma On Sat, Mar 20, 2010 at 6:34 PM, Jonas Bernoulli wrote: > On Sat, Mar 20, 2010 at 18:04, Alexander Surma > wrote: >> Well, resizehints are exactly that, hints. Not an obligation. >> It's usually the job of the window manager to respect (or not to >> respect) those hints - it's not >> something that has to be changed in the implementation of the terminal >> emulator. > > Let me rephrase: Does anyone know of a terminal that instead of > setting resize hints > (that would cause wmii to draw thicker boarders around the window [1]) > does not set > any resize hints but instead adds some extra space (in the background > color) on the > right and/or lower sides (or equally on all) (which does not have any > (truncated) text > on it) if the window size set by the window manager does set the > window to a size > which match a multitude of the font being used? > > [1] and which is worse often draws a thinner boarder, like in "of size 0px". > >
Re: [dev] terminal that accepts any size
Well, resizehints are exactly that, hints. Not an obligation. It's usually the job of the window manager to respect (or not to respect) those hints - it's not something that has to be changed in the implementation of the terminal emulator. Surma On Sat, Mar 20, 2010 at 5:48 PM, Jonas Bernoulli wrote: > On Sat, Mar 20, 2010 at 17:12, pancake wrote: >> ??? Size of what? >> >> Are you talking about resizehints? > > Yes. > >
Re: [dev] [dwm] Issue with openoffice fullscreen presentation
Isn't OOo just java too? So you *might* get that fixxed with the grey-windows-in-java-workarounds: either: wmname LG3D; unset AWT_TOOLKIT or: export AWT_TOOLKIT=MToolkit Surma On Thu, Mar 11, 2010 at 11:37 AM, Jakub Lach wrote: > 11 march 2010 10:25 Anselm R Garbe > >> Most likely openoffice requires a reparenting WM. >> >> I'd say file a bug report @openoffice.org. >> >> Cheers, >> Anselm >> >> > > I'm using OOo_DEV300_m71 (3.3) and have no such problem. > > regards, > -Jakub Lach > >
Re: [dev] HG and python
There's always git, the core of which is written in C, but some scripts are perl. And for the bloat: Git is sometimes percieved as somewhat more bloated (>100 little tools instead of 1 like hg) - that depends on the point of view. Surma On Wed, Mar 10, 2010 at 12:31 PM, Sylvain Bertrand wrote: > In war against bloat, python removal is on the todo list. > Is there any chance to use something different than hg for source > versioning and branching? > > -- > code in C, protect your code with GNU (A)(L)GPL, keep your rights, use > GNU/Linux > >
Re: [dev] Surf assumes all SSL connections are good, which is bad
Well, the connection is definitely encrypted. Regardless of a man in the middle or not ;) However - I see your point. My suggestion would be, that we allow yet another userscript to handle this. I for one do not care for verifying certificates. But for those who do, some kind of interface would be nice, woudln't it? Surma
Re: [dev] [dwm] Java Swing sucks, any solutions?
> I'm forced to use jmeter for the next two weeks at work. It's a swing > app. Swing and dwm don't seem to wrk at all. Doesn't the good ol' ``export AWT_TOOKIT=MToolkit'' work for ya? If not, define "not working". Surma
Re: [dev] include files should never include include files?
Of course you did not run into problems. You just wasted your precious processor time on including and parsing header files which you could have easily prevented by following that rule. You might however run into problems when breaking this rule and no #ifdef-guards are present. I'm not sure about C++, but I'd say the rule applys as well. You never compile a header on it's own so you should put all the includes into the C files from the beginning. Surma On Sat, Jan 16, 2010 at 4:41 PM, Joseph Xu wrote: > A little off topic maybe, hope I'll be forgiven ... > > I'm reading Rob Pike's C programming style guide > (http://www.quut.com/c/pikestyle.html), and the last rule says: > > -- > > Simple rule: include files should never include include files. If > instead they state (in comments or implicitly) what files they need to > have included first, the problem of deciding which files to include is > pushed to the user (programmer) but in a way that's easy to handle and > that, by construction, avoids multiple inclusions. Multiple inclusions > are a bane of systems programming. It's not rare to have files included > five or more times to compile a single C source file. The Unix > /usr/include/sys stuff is terrible this way. > > There's a little dance involving #ifdef's that can prevent a file > being read twice, but it's usually done wrong in practice - the #ifdef's > are in the file itself, not the file that includes it. The result is > often thousands of needless lines of code passing through the lexical > analyzer, which is (in good compilers) the most expensive phase. > > Just follow the simple rule. > > -- > > This is a little surprising to me as I'm used to putting includes in > include files all the time. I do use #ifdef header guards, and I've > never really had any problems violating this rule. So my first question > is, has anybody actually ran into problems due to violating this rule? > And secondly, does this rule apply to C++? For example, if I'm defining > a class that std::vector members, I ordinarily add a #include in > the header. > > > Thanks for the advice. > > Joseph > >
Re: [dev] stali and the shipped compilers
The configurations of the compilers can usually be extracted from the executable with ``gfortran -v'' Surma On Thu, Jan 14, 2010 at 9:42 PM, pancake wrote: > I would prefer to drop gcc, glibc and all the shit from gnu. > > Tcc and dietlibc are usable solutions and maybe the code is not the best one > but at least is sane. > > Current toolchain is just to get a working version. I know that anselm is > really busy these days, like me.. This is the reason why some of those > projects are a bit stopped. > > Is there any minimal and complete fortran implementation? > > On Jan 14, 2010, at 9:02 PM, Jimmy Tang wrote: > >> Hi All, >> >> I've been looking at the shipped compilers in the stali repo, I was >> just wondering how the compilers were configured. I'm interested in >> enabling gfortran for my own uses and testing. >> >> Thanks, >> Jimmy >> >> -- >> Jimmy Tang >> Trinity Centre for High Performance Computing, >> Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. >> http://www.tchpc.tcd.ie/ | http://www.tchpc.tcd.ie/~jtang > >
Re: [dev] [bug] [dwm] Resolution chages
Yes, can confirm both. I'll do some research on the details. Surma PS: I do too, and I still regret very much my lack of presence later that night - so to speak ;) On Sun, Jan 10, 2010 at 6:37 PM, Moritz Wilhelmy wrote: > Hi, > > I can at least confirm that xrandr -s does not work with dwm 5.2 > didn't try --output > > Moritz > > On Sun, Jan 10, 2010 at 05:04:48PM +, Anselm R Garbe wrote: >> Hi, >> >> this seems to be an issue in certain Xinerama implementations, I >> identified the following a while ago: >> >> xrandr -s reproduces the issue you notice, whereas >> >> xrandr --output XY --mode wxh >> >> etc does work. Can you confirm? >> >> Cheers, >> Anselm >> >> PS: Still remember our Skat session ;) >> >> 2010/1/10 Alexander Surma : >> > Hi, >> > Just wanted to file a bug report, that dwm doesn't handle a change of >> > the screen resolution very well. >> > When I change to a low resolution (640x480), everything seems fine, >> > but if I change back (1280x1024) I have parts of my background in the >> > statusbar. >> > >> > Not urgent, but wanted to let you know. >> > >> > Surma >> > >> > >> >> > >
[dev] [bug] [dwm] Resolution chages
Hi, Just wanted to file a bug report, that dwm doesn't handle a change of the screen resolution very well. When I change to a low resolution (640x480), everything seems fine, but if I change back (1280x1024) I have parts of my background in the statusbar. Not urgent, but wanted to let you know. Surma
Re: [dev] slock - cannot log in
> No. A screen locker locks the system completely (apart from remote logins). That's how it's supposed to be at least. I've encountered a lot screenlockers which let me switch to console anytime. regarding the problem: That's why I leave ssh running - X locks up (or at least takes no input) and I can restart X from remote. Let's hope you have ssh running, too. (btw: Telnet will also do the job ^^) Surma
Re: [dev] sup - the minimalistic sudo
> I know that there's a really-cool mail client called 'sup'.. so if you have > any other > proposal for the name? 's'? 'sp'? 'sudor'? smudo? a jungled-up acronym for "minimal super do"? Kind of a german insider, but it has a nice ring to it ;) I like sup alot, btw.
Re: [dev] [surf] some potential bugs and some user questions
> 1- for some reason surf stalls for a couple of seconds on a new page, > I just hit ctrl-g suckless.org and it stalled for 11sec! Can't confirm that. > 2- Download seems to be broken. (in tip and 0.3 from hg) I get > (:27178): GLib-GIO-CRITICAL **: g_output_stream_write_all: > assertion `G_IS_OUTPUT_STREAM (stream)' failed > console message: �...@1: Refused to set unsafe header "Connection" Confirm > 3- ~.surf/dj was created as a file not a dir (tip) I sent a patch for that to the mailinglist a few days back. Just append a '/' in the config.h to the dldir path. > 5- I don't fully undestand the Copy URI why it isn't putting the URL > in the clipboard? Confirm
Re: [dev] suckless password manager
Actually, I think passwordmanagers are not secure. All your passwords are just as strong as your PM encryption. I have an mnemoc/algorithm which enables me to generate a quite strong password (without pen&paper) which depends on the name of the webpage and/or username I use there. On Dec 10, 2009 11:55 PM, "anonymous" wrote: On Thu, Dec 10, 2009 at 11:14:15PM +0100, Nibble wrote: > Hi, > > It is just a little "toy", but ma... It can't work with X, but use of GPG instead of creating new encryption scheme is interesting. So the only thing to implement is secure use of X11 clipboard and integration with GPG or some PGP library. And what password managers do suckless developers use? Not using any doesn't seem secure, I don't think someone can lots of good passwords.
Re: [dev] [dmenu] Vertical bug
I can almost confirm this. It seems like -l values <6 are ignored and 6 ist used. Values>6 are correctlz uses. On Dec 2, 2009 8:50 PM, "Tadeusz Sośnierz" wrote: Hello, Looks like dmenu (in tip) ignores the -l argument, assuming 10 anyway. Regards, Ted
Re: [dev] [dmenu] pasting bug
Which version are you talking about? I myself don't even have a cursor
or the ability to paste in stable.
Surma
2009/12/1 Tadeusz Sośnierz :
> Hello,
> I think there's a bug in pasting functionality. Steps to reproduce:
> 1. run dmenu
> 2. open some quotation (e.g. ")
> 3. paste some text
> 4. notice that the cursor has not moved
> 5. typing anything, e.g. closing qoutations makes dmenu delete the
> pasted text
>
> Also, when you type two quotations ("") then move the cursor between
> them, and then paste, the paste goes at the end of the text instead of
> being put between quotes.
>
> Kind regards,
> Ted
>
>
[dev] Re: [surf] PATCH for default directory path - really uncritical
As Richard Pöttler pointed out correctly, I forgot to attach the patch. Here ya go - sorry about that. Surma dl-dir.patch Description: Binary data
[dev] [surf] PATCH surppress error message when _SURF_URI is empty
Another small patch for supressing an error in dmenu's output when _SURF_URI is not set (as it happens when surf just started). This is probably not the nice way to do it, but liek this I didn't have to touch the code. Surma empty-url.patch Description: Binary data
[dev] [surf] PATCH for default directory path - really uncritical
Hi, I just figured out how buildpath() worked and that as a consequence the default value of dldir is useless. It causes buildpath() so create a file rather than a directory. So here's a one-line patch. Surma
