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] revolution
> Wait in fact I don't know what that means. In fact, the word I wanted to use was 'preferences'. ;)
Re: [dev] revolution
Or this person just has some simple privileges that are not met by dwm or any other window manager he knows of. Kurt you should sometimes just simply shut the fuck up and go out and get some life instead of pissing around and being unfriendly despite naiveness of the question asked. ... On 06/11/2011 01:45 PM, Kurt H Maier wrote: > On Sat, Jun 11, 2011 at 6:56 AM, Le Tian wrote: >> I did it, because just recently have met a guy, who was insisting that >> it is better because this and that. > > And now you know: that guy was either an idiot or a troll. You are > probably now able to decide which.
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
> 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/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] Suckless UML
On 05/11/2011 07:02 AM, CHABOT Simon wrote: > I have already used it to draw graph, but never I never though to try it for > UML. I take a look ! In case you add documentation with doxygen to some projects, you can use it to produce UML diagrams of your classes. Doxygen itself uses dot... So using this you could simply write down class definitions and let doxygen/dot do the rest. 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] Re: Simple port scanner again
On 03/08/2010 01:05 AM, anonymous wrote: > Erlang is not good to write a port scanner. Do you have any sane justification for this remarque?
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] GSoC 2010
On 03/03/2010 02:46 PM, Peter John Hartman wrote: > I agree about the issue trackers + the mail integration. A small > suggestion: none of the issue/bug tracking systems do collaboration very > well either. What I mean by "collaboration" is the capacity to pass a > single document back and forth with several "notes" appended to it. a > giant You might think on a distributed bug-tracking system similar to a list of bug-reports inside a git system with the possibility to create new bugreports "on the fly" when the mail-server receives a specific mail (you somehow have to define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). There should be a 'central' (though not required) bug-tracking server for all those coming with bugs on you project-website. there, the current bug list and state is a available and an interface to add new bugs. then you could place some sort of hooks into your bugtracker (bt) configuration: bt/.config/new -> send mail to mail-adress with new bug then you can manage bug-notification via mailing lists. For users that don't want to use the website, you could listen on mails in a specific form/with a specific header to pass it directly to bt parsing it. if the parsing fails, automagically send a mail back to the composer with annotation where it failed, if successfull, send back a success-mail. usage could be like (in a distributed way): $ cd bugs/projectname bugs/projectname $ bt pull # pulls all new bugreports from server 7 new bugreports bugs/projectname $ 51 unresolved bugs 123 pending bugs where 'pending' means that their state is in "needs check if the bugfix works or not, waiting for approval" or something like that. If you want to make comments to a file, make them and afterwards a bugs/projectname $ bt commit -m "some annotation" bugs/projectname $ bt send # send new file to whole mailinglist bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a specific user would do the rest. something like that. Didn't think too carefully on it.
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] [OFFTOPIC] Recommended meta-build system
On 02/01/2010 10:25 PM, Uriel wrote: > If you define your personal identity based on the colors of your > fucking window manager I feel sorry for your pathetic worthless life. This is not the first time that you confuse cause and result. Additionally, you seem to not have a fucking clue about people's different perception of the world around them (e.g. emotional/biophysical influence on colors) or the most mundane knowledge of psychophysics in general. You should definitely stop talking about this topic if you don't want to ridicule yourself anymore.
Re: [dev] [OFFTOPIC] Recommended meta-build system
On 02/01/2010 12:02 PM, Uriel wrote: > People are retards that should get a life, and developers that can't > pick bearable colors should not pick colors (just ask for advice from > an artists as Rob did for acme and rio). Desktop Look&Feel Communism up ahead. Yours is the most retarded and human-diversification-ignoring comment I read in a long while now on this mailing list.
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] [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] 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
