It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.
While I can understand why transparency is a bad idea, people have the
freedom to want whatever they want. If the maintainers of the software
don't want a particular feature in vanilla, a
> People who support dumb things run the risk of mockery. I'd rather
> get burned for suggesting something stupid than have this list turn
> into a politically-correct hugbox support forum for the criminally
> inept. If you don't like it, go hang out on another mailing list.
Well if you really w
> I'm sure you could have a ton of field days, describing for hours all
> kinds of irrelevant crap. Maybe you can read a book about adapting to
> different standards within different social groups instead of
> lecturing to people who don't care. It's a mailing list. Calling
> people stupid is no
> I'm suggesting that if you want two clearly distinct jobs done, and
> they share a lot of similar code, you extract the duplicate code into
> a library and then write two applications against that library.
No you weren't.
> In this case, we should wind up with st, which consumes PTYs and emulat
> My clarification of my position was exactly as connected to previous
> statements as your accusation of the garbage you were spouting about
> no new functionality or whatever. Incidentally, this thread now
> stands as a counterexample to your hypothesis regarding the inability
> of petty argumen
Hi,
I had the same problem. It's a strange error and I haven't taken the
time to work out exactly what's causing it, but a quick fix is to copy
the functions directly into the main dwm.c and declaring function
prototypes for those functions before the #include "config.h" line.
For example:
...
s
2009/11/8 Szabolcs Nagy :
> don't do that
> include the .c files in the appropriate place in config.h instead (eg
> right before layouts)
That's what he's doing, that's where the problem is...
There seems to be a bug when some patches are applied that prevents
functions included from within confi
ter config.h
is included. This creates an obvious conflict with the method of
including extra functions in config.h when those functions make use of
the 'Monitor' struct.
2009/11/8 Aled Gest :
> 2009/11/8 Szabolcs Nagy :
>> don't do that
>> include the .c files in t
2009/11/8 Bartosz Nitkiewicz :
> So, the solution is not to use pertag with other patches becouse one excludes
> the other.
If you can live without either one or the other then sure. Not really
an option for me but I don't mind patching the functions directly into
dwm.c, that's where the preproce
2009/11/11 Preben Randhol :
> Syntactically the language seems a bit confusing at first and
> unfortunately too similar to C.
I don't get what people have against the C syntax. It's the cleanest
and most logical syntax I've come across so far.
Has anybody had any experience compiling Go on BSD ye
2009/11/11 markus schnalke :
> Then you never tried Lisp!
I hope that's sarcasm, because I wouldn't call requiring everything to
be wrapped in parentheses clean :P
2009/11/11 Antoni Grzymala :
> Looks like you didn't give more than half a minute's time, to see what
> Lisp's syntax (or rather the lack of it) is actually about. Your hopes
> are vain.
It doesn't take long to judge clarity. Perhaps experience is a
critical factor but to me it seems a lot easier
2009/11/12 markus schnalke :
> Remember: ``Unix is simple. It just takes a genius to understand its
> simplicity.'' (dmr)
Not quite sure what point you're trying to make here. Unix has a nice
philosophy, there are plenty of poor implementations of that
philosophy though. If you're suggesting that
2009/11/12 markus schnalke :
> You said something like that a quick look at the syntax lets you judge
> if it is clean/nice/whatever or not.
>
> I posted the above quote to show you that even simple things may not
> be easy to see.
I said "It doesn't take long to judge clarity". If it's not easy t
2009/11/13 Moritz Wilhelmy :
> In lisp, the macros are part of the language and don't hide anything.
> The syntax itself is lisp, with all it's parentheses.
I'm only going by what Dimitry Maluka was suggesting in his e-mail. I
don't see the point of writing complex macros to subdue a language to
m
2009/11/13 Mate Nagy :
> please stop posting
Why?
2009/11/13 Antoni Grzymala :
> It's getting very much off topic.
That's why it's marked with [OT], and that's why I moved it out of the
Go thread. I suspect the objection is more to do with people not
liking to hear criticism about things they're fond of.
> If you would care for a pleasant
> (rea
2009/11/15 Uriel :
> What dependencies?
These ones:
> It has a runtime and a set of libraries, no
> different from C++
Those are drawbacks IMO. I avoid the C standard library where I can
and I certainly avoid the C++ standard library like the plague, and
just in case it wasn't clear, I hate C++
On 4 April 2010 23:32, Paul Malherbe wrote:
> Again I totally agree with Uriel, rather use a good scripting language like
> python ;-)
While I personally would choose scripting in a decent scripting
language over doing anything but basic stuff in a shell script, one
very valid reason for choosing
Isn't all this the purpose of the 'lsx' tool?
http://tools.suckless.org/lsx
Admittedly it doesn't handle caching, but a hybrid between shell and
the lsx tool might result in faster cache regeneration.
Regards,
Al Gest
On 19 May 2010 09:04, Elmo Todurov wrote:
> Hi there.
>
> I rewrote dmenu_pa
On 21 June 2010 06:09, Robert Ransom wrote:
> Scheme *should* be used for almost everything -- bootloaders, OS
> kernels, hardware drivers, tiny user utilities (like (Plan 9) ls and
> mc; Unix ls no longer qualifies as a tiny utility, and should not be
> written at all), long-running servers, etc
> Scheme *should* be used for everything because at least one good macro
> system has been designed for it. Lisp macros can do arbitrary
> computation at compile-time, and the Scheme macro system required by
> R6RS provides all the power of Lisp macros *and* supports a
> pattern-matching macro spe
> * Because manual memory management is a mess.
>
> * Because some data structures and algorithms (red-black trees, for a
> classic example) are extremely cumbersome in C compared to other
> languages.
Hiding complexity from a programmer does not improve the situation, it
simply removes th
> But C does that, too. With C, you are writing in a language quite
> removed from the actual instructions the processor executes; it's
> hiding the complexity of machine code. So, if we take you at your
> word, you are advocating returning to writing assembly code. As
> someone who wrote his first
> No. The extent to which you employ abstraction (in the sense of how
> your code is architected) is your choice in Scheme and in C. What
> Scheme gives you is very clean semantics, simple syntax, and garbage
> collection. Together this makes creating correct code a great deal
> easier, at the cost
> sorry, but I'm not sure that the burden of proof is on him.
It isn't, which is why I'm not demanding proof from him. It was simply
a gesture that I would be interested to see well written practical
examples of Scheme or Lisp in action.
> Furthermore, I don't think the whole "I hate everything y
> Yes, wasting resources is a Bad Thing, by the strict definition of
> 'waste' -- cost with no benefit. But if you use more of one
> inexpensive resource in order to reduce the use of another expensive
> resource and achieve a net gain in the process, that's not waste,
> that's smart.
I'm still a
Just tested it on my OpenBSD box and it works nicely with sic.
There is one fix that's needed for BSD distros, on BSD forkpty() is
provided in rather than , I fixed it with:
#ifdef LINUX
#include
#else
#include
#endif
It's not the most portable of fixes so it might require extra
conditions fo
Made a small patch to remove the requirement of specifying -DLINUX in
config.mk. The define should actually be __linux__ not LINUX. My
apologies for supplying you with the wrong info.
Regards,
Al Gest
srw-0.3-linuxfix.diff
Description: Binary data
Personally I like any music that is (in my mind) well constructed,
sounds good, and isn't pretentious, regardless of genere. I do have a
penchant for Trance music, but I don't like to keep my options limited
so my taste ranges across a lot of generes.
A very small sample of what I listen to: 2pac,
In relation to enviornment variables for configuration. I've often
considered the possibility of using the 'envdir' tool from DJB's
daemontools package for simple configuration in things like dwm.
http://cr.yp.to/daemontools/envdir.html
It's a simple tool that sets environment variables based on
31 matches
Mail list logo
