Re: [dev] Experimental editor
On 06/17/2011 10:37 AM, markus schnalke wrote: For the same reason we want Unix's manifold toolchain and for the same reason we want several programming languages: Because ``One fits all'' is an illusion. Then try to figure out some basic tools that you can glue together to form a fully functional editor. 'Reinventing' an editor for every purpose and most probably copying some things on source level from one editor to the next is ridiculous.
Re: [dev] ideas on suckless file manager
On 06/07/2011 07:09 PM, pancake wrote: Its anti natural. It's not. Because I asked myself which is the best working environment regarding ones eyes some time ago, I looked around for some scientific research on the topic of black-background vs white background. There's not that much research to be cited (and to be honest, after reading the papers I removed them) but the overall conclusion is that most probants had a higher reading speed and slightly less reading errors with black text on white background. Nevertheless, the differences are very small. In the end it comes down to personal preference. Additionally, I looked around for some research regarding eye health w.r.t. black- vs white-background because one common 'understanding' seems to be that your eyes will be treated more friendly with a black background. Again, none of the research papers I read (origin from about 1970 - 2008 or so, when I have some time and the will to I'll search the papers) came to the conclusion that this is true. Quite the opposite, that they could not detect any difference. The only clear direction stated was that when you have to work with a monitor and feel that your eyes are tiring, you should probably go to an optician as you might have a minor amblyopia (+.25, -.25 something like that) and proper way to work against it is to try eyeglasses. regards
Re: [dev] Suckless UML
I am saying if your code needs UML documentation to be understood, then it is not suckless. I fully agree. Also, I tend to dislike auto-generated documentation because the valuable part is very small and hidden among loads of crap. That depends on the tool you (have to) use. As an example, if you're only interested in a class diagram (and possibly some small documentation) doxygen will help you right away. I don't say that doxygen is great, but in this case the resulting diagram will most likely be the same as if you were to write the dot-file manually. you will often end up with something that does not explain better how the code works. If you try to cheat yourself you're doing something wrong anyway. But to the point: The purpose of a class or component diagram is not to tell you how your code works. In fact, even an activity diagram won't show you how it does something but what it does. And to be honest, I don't know of any tool to automatically generate the latter diagram. In my experience you're doing something wrong in your project if you can't denote the data-flow or execution order by a simple A - B - C because you can ultimately reduce this sort of thing into a mathematical formulation of your processing. This, of course, doesn't fully hold true when you're to write anything that does computations in parallel. I still have to find any sane mathematical notation for parallelism in programming languages though... regards
Re: [dev] Suckless UML
On 05/12/2011 03:51 PM, Nicolai Waniek wrote: I still have to find any sane mathematical notation for parallelism in programming languages though... Of course CSP goes in this direction, but as soon as your language is not based on CSP in any way, you yet again have to document describing the translation from CSP to the programming language at hand and vice versa.
Re: [dev] Suckless UML
On 05/10/2011 04:57 PM, Christophe-Marie Duquesne wrote: Good code is supposed to be readable, and should need no UML diagram (and probably very few comments). Though you're right that it should not _need_ a UML diagram, having one isn't that bad either. This is especially true when you're not just working on your hobby-4k-LOC-project but within a team on a somewhat larger project. Or on a project that requires some sort of 'class hierarchy'. Or... the list continues. Though UML is not the best thing at all and it is heavily bloated (especially since UML 2.0, guess most things with a 2.0 in it is just fucked up) I'd like to punch everyone in the face inventing his or her own fancy documentation graphics when there's at least something everyone else would recognize without the need to read an additional explanation on what the graph wants to present. (this point is of course invalid when your working group/team has decided on a certain graphical annotation set). Very often using something like UML is faster when discerning class-interactions or hierarchies than looking at the code. regards
Re: [dev] [OT] What's wrong with C++?
On 09/10/2010 07:46 PM, v4hn wrote: On Fri, Sep 10, 2010 at 08:19:38PM +0300, Nikhilesh S wrote: I haven't really understood the problems with C++ that the people here that have problems with C++ have[...] Felix von Leitner gave a pretty good presentation in 2007 on such problems :) http://www.fefe.de/c++/c%2b%2b-talk.pdf From looking at FeFe's presentation just some notes: His complaints are mostly corner cases. You can produce some stupid corner cases where the language sucks for every language. Additionally from someone who can't properly code (look at his open source stuff...) one should simply stop reading when he's complaining about possibly cryptic compiler output...
Re: [dev] Surf 0.4 issues
I guess you should make your configuration changes to config.h instead of config.def.h. the latter one is there to have some 'reference configuration' if you have f***ed up your config.h. regards
Re: [dev] GSoC 2010
On 03/03/2010 06:28 PM, Anders Andersson wrote: What would be the benefits of porting dwm to a new language? From my point of view, dwm is already functional and mature, porting it over to Go doesn't sound very constructive. And porting it is a real pain, at the moment. For example, you don't have bindings to xlib. It is possible via cgo to create bindings, but it's not that straightforward to use them. If the decision is made to take xgb (the xcb port for Go), one will notice that xgb is a rather premature state. Some time ago I tried out small apps with xcb (to get familiar with it) in C, and one of them was to simply port dwm's most basic functionality to xcb. About 4 weeks ago I tried to port this to Go and xgb, which resulted in me changing the xgb part because somehow the xgb developers lost track and sense what xgb is. For example, instead of having an error handler facility, xgb prints out the error and even worse - in some cases you don't have the possibilty to get the error at all or even don't get a status that an error occured, the only thing that happens is that an error message is written to stdout... That said, when thinking about porting dwm to something like go and despite that I don't really like xcb, a stable/working/sane/suckless xgb would be a decent way to go as with Go's easy multithreading, the asynchronity would reach another level. nw
Re: [dev] [dwm] Java Swing sucks, any solutions?
On 02/05/2010 03:47 PM, Alexander Surma wrote: 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 In most swing/awt-applications, this will cause a sigsegv (especially under amd64). I got best results with: $ wmname LG3D $ unset AWT_TOOLKIT $ run_your_app
Re: [dev] [dwm] sdl12 / dwm 5.6 /5.7.2 ioquake3 problems
On 02/01/2010 08:05 AM, Anselm R Garbe wrote: What do you exactly mean? I guess he means that when dragging windows in float mode, some applications behave like f***. For example, start a ddd session over ssh and move the window around when the debugger is running. Though I'm using xmonad, the behaviour might appear in dwm as well. regards, nicolai
Re: [dev] [dwm] sdl12 / dwm 5.6 /5.7.2 ioquake3 problems
Oh and what he might mean with outline moving: just drawing the outline of a window that is to be moved, looking as if you only move around its border to the window's future position and not actually moving the window until you have decided where to place it.
Re: [dev] licenses (was: simple portscanner)
On 01/03/2010 01:11 AM, hiro wrote: Often it's better to listen to your intuition and ignore German laws. Especially if you are no lawyer and just read about so-called laws on Wikipedia. most stupid idea ever. if you're in the software industry and wish to make your source public you should at least know the potential backdraws of your country's IP laws (regardless how stupid they may sound) and act properly to make sure every single person using your stuff might not face any problems. I have seen that German rules regarding the internet are most vague; perhaps only to me, because I'm stupid, but I'd like to have the reader make that decision. as you can't really pass your copyright in germany you should definitely base your publication on some means of 'contract'/license to protect the one using your code from you going mad and coming after him with some creepy lawyer. this said, you best use something that has already gained some attention in a german court. yes, my answer is based on a purely german-centric view.
Re: [dev] [st] goals / non-goals for st?
Moritz Wilhelmy wrote: On Fri, Oct 30, 2009 at 04:01:43PM -0500, Kurt H Maier wrote: xmessage can read from pipes? make xmessage read from stdin with the -file - option, e.g. echo mmh | xmessage -file - regards, Nicolai
