Re: [dev] Suckless design in Games

[lordkrandel]

On 11/08/2010 2.09, Alex Hutton wrote:

An idea I had the other day, and this is for dealing with data
compartmentation in games, was to write a game in C and use sqlite for
all the data. I've never used sqlite so I don't know how the
performance would go, but it seems like a good idea to store all the
data in a relational database as it makes it less likely that the data
structures would have to be refactored during development and it
allows me to avoid having to use 'objects'.



SQL databases

Less Harmful:
Tutorial D, pq, BigTable, plain old hierarchical filesystems.

from http://harmful.cat-v.org/software/ by Uriel

--
Wyrmskull

Re: [dev] Suckless design in Games

[Chidambaram Annamalai]

On Wed, Aug 11, 2010 at 12:24 PM, Szabolcs Nagy  wrote:

> * Chidambaram Annamalai  [2010-08-11 03:26:22
> +0530]:
> > I didn't argue BGL was simple. But I'd certainly consider it elegant. Of
>
> no it's not elegant
>
> graph algorithms are too versatile to do elegantly what boost tries to do
> (eg boost tries to operate on a generic graph type which cannot work
> as different graph representations often require different algorithms
> also space-time and other important tradoffs cannot be expressed this way)
>

Have you even bothered to look through the sources? You really have
absolutely NO idea what you're talking about. The whole idea behind BGL is
to decouple the storage schemes from the algorithms so that you can write
O(M + N) code to support O(M*N) template instances. And there is no point if
this abstraction had a severe penalty on the runtime performance. BGL
exactly knows which algorithm to use for a particular storage mode because
intelligence is built into it using traits. The hierarchial design (which is
conceptually like OO inheritance) is to elimiate code bloat almost entirely,
by only instantiating template classes that are absolutely essential.

RTFM: http://portal.acm.org/citation.cfm?id=320385.320428


in bgl a shortest path algorithm has 12 arguments some of them are type
> parameters some of them are objects with various methods defined on them
> generic programming is mixed with oo inheritence all over the place
>

Template metaprogramming uses static polymorphism which is an entirely
different beast from OO inheritance that uses dynamic polymorphism.

Re: [dev] Suckless design in Games

[Mate Nagy]

On Tue, Aug 10, 2010 at 12:39:24PM -0700, Robert Ransom wrote:
> This list is a subculture itself (as is the 9fans list).
 wait what? i thought this list *was* the 9fetish^wfans list

M.

Re: [dev] Suckless design in Games

[lordkrandel]

I will, however, point out one consequence of that idea: the most
noticeable difference between abstract art and abstract mathematics is
that abstract mathematics has some aesthetic value.  Abstract art can
now consist of a canvas painted one color, or mere splatters of paint
(or other substances) on a surface; contrast that with the Mandelbrot
and Julia sets, or the Hilbert and Peano space-filling curves and von
Koch snowflake, or the elegant complexity which arises from the simple
axioms of group theory.  A pure mathematician does his work to satisfy
his curiosity; an abstract artist does his work merely to see what he
can get away with.


An artist is moved by curiosity about the world and himself just
as scientists do in a rational way. The author satisfies this need
through his work. You can find beauty in both a paint and a formal
description of a theory. One can write songs to have a better and
full understanding of what he is feeling and to try to convey his
emotions to others, just like mathematicians convey their knowledge
about the world through axioms, rules, laws, models.


I will also point out that a game does have a function -- to be fun.

Define in an objective way: to be fun. :P
It is not a tool like hammers, "cat" command or applied maths.
I'm thinking about applied coding, pure coding, and applied pure coding.
Sounds almost like Kant xD


I like Mozart and Minimalism just as much as I like Dadaism or free
Jazz, even if they have different forms and subjective functions.

I hope you aren't suggesting that Mozart *is* minimalist.


It was an example of "elegance", to pinpoint the delta with Dadaism.


Robert Ransom


--
Wyrmskull

Re: [dev] Suckless design in Games

[Antoni Grzymala]

Robert Ransom dixit (2010-08-10, 23:12):

> > I like Mozart and Minimalism just as much as I like Dadaism or free
> > Jazz, even if they have different forms and subjective functions.
> 
> I hope you aren't suggesting that Mozart *is* minimalist.

He most definitely is (along with Chopin, I'd argue) – at the opposite
end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday.

-- 
[a]


pgph7IFwpuoBn.pgp
Description: PGP signature

Re: [dev] sta.li - a few questions about it

[Robert Ransom]

On Tue, 10 Aug 2010 17:32:51 -0400
m...@distasis.com wrote:

> I'd love to just find a stable, backward compatible Open Source system so I 
> can concentrate on what I like most, getting interesting and useful programs 
> to build and work on the system.  Good luck with the sta.li project and if 
> there's something I can do to help, let me know.

I think the sta.li developers are likely to toss backwards
compatibility with some existing software in favor of simplicity.

If you are planning to write new software, you may be interested in
Inferno (you can find your way to it from ).  It
runs on Windows and Linux now, and it *will* run on sta.li someday.


Robert Ransom


signature.asc
Description: PGP signature

Re: [dev] Suckless design in Games

[Robert Ransom]

On Wed, 11 Aug 2010 10:16:07 +0200
lordkrandel  wrote:

> > I will, however, point out one consequence of that idea: the most
> > noticeable difference between abstract art and abstract mathematics is
> > that abstract mathematics has some aesthetic value.  Abstract art can
> > now consist of a canvas painted one color, or mere splatters of paint
> > (or other substances) on a surface; contrast that with the Mandelbrot
> > and Julia sets, or the Hilbert and Peano space-filling curves and von
> > Koch snowflake, or the elegant complexity which arises from the simple
> > axioms of group theory.  A pure mathematician does his work to satisfy
> > his curiosity; an abstract artist does his work merely to see what he
> > can get away with.
> 
> An artist is moved by curiosity about the world and himself just
> as scientists do in a rational way. The author satisfies this need
> through his work. You can find beauty in both a paint and a formal
> description of a theory. One can write songs to have a better and
> full understanding of what he is feeling and to try to convey his
> emotions to others, just like mathematicians convey their knowledge
> about the world through axioms, rules, laws, models.

They are not abstract artists.  Their works of art have functions.  (A
work's function includes ‘feeding its creator(s)’ surprisingly often.)


> > I will also point out that a game does have a function -- to be fun.
> Define in an objective way: to be fun. :P

Oh goody.  A philosopher.


A computer game is a computer program whose creator intended primarily
that human beings enjoy interacting with it.

If you want an objective definition of ‘to enjoy’, ask a neurologist;
they are finally starting to understand this sort of simple emotion.
As I understand it, a human being (or other animal) enjoys an activity
if the activity causes certain cells in his/her/its brain to produce
and/or release dopamine.

If you want an objective definition of ‘intended’, ‘interacting’,
‘computer program’, ‘human being’, ‘animal’, ‘cell’, ‘brain’,
‘dopamine’, ‘produce’, ‘release’, or ‘neurologist’,  *** *** ***
*** *.  Uriel can elaborate on that if you want (or if you
don't want).


To the extent that this list has a topic, it seems to be ‘the philosophy
of computer programming’.  That does not mean that any of us want to
read the kind of crap [that *is* a noun, right?] that university
departments of Philosophy emit.


> It is not a tool like hammers, "cat" command or applied maths.
> I'm thinking about applied coding, pure coding, and applied pure coding.
> Sounds almost like Kant xD

*** *** *!


> >> I like Mozart and Minimalism just as much as I like Dadaism or free
> >> Jazz, even if they have different forms and subjective functions.
> > I hope you aren't suggesting that Mozart *is* minimalist.
> 
> It was an example of "elegance", to pinpoint the delta with Dadaism.

Well, at least you have a glimmer of sanity.


Robert Ransom


signature.asc
Description: PGP signature

Re: [dev] Suckless design in Games

[lordkrandel]

A computer game is a computer program whose creator intended primarily
that human beings enjoy interacting with it.


I was just arguing that the idea of "suckless design" may fit not so 
well in game programming.


That's why at a certain point I answered a message in a private way
but then the reply came on the mailing list. Sorry for the "crap".

> To the extent that this list has a topic, it seems to be ‘the
> philosophy  of computer programming’.  That does not mean that any of
> us want to read the kind of crap [that *is* a noun, right?] that
> university departments of Philosophy emit.

Suckless dev also means discussing about what "suckless design" is.

I'll never quit saying: If you are not interested, do not read, do not
reply.

I'll get back when I have a -n lines patch so you will all be happy.


Robert Ransom


--
Wyrmskull

[dev] off topic - awk versions performance comparison

[Joseph Xu]

Hi everyone,

I was playing around with awk and ran into some surprising data for the 
function match(s, r), which returns the position of the first match of 
regular expression r in string s. Here's the test I ran:


$ yes | head -1 | tr -d '\n' >/tmp/big
$ yes | head -100 | tr -d '\n' >/tmp/bigger
$ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big

real0m0.056s
user0m0.053s
sys 0m0.000s
$ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger

real0m5.695s
user0m5.140s
sys 0m0.553s

The difference is almost exactly 100x, which is the size difference 
between the input files. It seems ridiculous that the amount of time 
taken to match the first character of a string grows linearly with the 
size of the string. The time it takes to load the contents of the file 
does not contribute significantly to this increase.


That was GNU awk. Trying p9p awk:

$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big

real0m0.024s
user0m0.023s
sys 0m0.000s
$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger

real0m1.856s
user0m1.857s
sys 0m0.000s

This is a lot faster compared to GNU awk but there's still a 77x 
difference between the two input files.


Finally, trying Kernighan's One True Awk (from 
http://www.cs.princeton.edu/~bwk/btl.mirror/awk.tar.gz)


$ time nawk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big

real0m0.001s
user0m0.000s
sys 0m0.000s
$ time nawk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger

real0m0.015s
user0m0.010s
sys 0m0.003s

The time difference here is actually only due to loading a larger file:

$ time nawk '{ }' /tmp/big

real0m0.001s
user0m0.000s
sys 0m0.000s
$ time nawk '{ }' /tmp/bigger

real0m0.016s
user0m0.013s
sys 0m0.003s

So at least nawk's performance makes sense. To make things a little more 
confusing, I tried matching on a non-existent pattern:


$ time awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.005s
user0m0.003s
sys 0m0.000s
$ time awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m0.085s
user0m0.080s
sys 0m0.003s
$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.006s
user0m0.003s
sys 0m0.000s
$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m0.077s
user0m0.077s
sys 0m0.000s
$ time nawk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.007s
user0m0.007s
sys 0m0.000s
$ time nawk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m0.612s
user0m0.607s
sys 0m0.003s

Now GNU awk and p9p awk are showing on the order of 10x differences 
between the two files, while nawk shows 100x difference. Obviously the 
regex algorithm that nawk uses is different from the other two, and 
there's a trade off here, though nawk still looks superior.


Last test:

$ echo -n 'z' >>/tmp/big
$ echo -n 'z' >>/tmp/bigger

Now the pattern does match, but at the very end of the string.

$ time awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.056s
user0m0.057s
sys 0m0.000s
$ time awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m5.861s
user0m5.270s
sys 0m0.590s
$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.057s
user0m0.057s
sys 0m0.000s
$ time 9 awk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m4.760s
user0m4.756s
sys 0m0.000s
$ time nawk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/big

real0m0.007s
user0m0.007s
sys 0m0.000s
$ time nawk '{for (i=1; i < 100; i++) { match($0, "z")} }' /tmp/bigger

real0m0.612s
user0m0.610s
sys 0m0.003s

In this case all the numbers make sense, assuming a linear scan is going on.

Can someone shed some light on these vastly different numbers? Why do 
GNU awk and p9p awk perform so poorly on the easy case where they just 
have to match the first character?

Re: [dev] [wmii] Wmii breaks block selection in kicad

[Kris Maglione]

On Sun, Aug 08, 2010 at 05:42:57PM +0200, Daniel wrote:

I use wmii excusively as my WM, but I encountered strange problem:
block selection (left mouse click+drag) does not work in kicad under wnii.

kicad is EDA software: http://iut-tice.ujf-grenoble.fr/kicad/
Im using version BZR R2356  (stable, 5.05.2010)
with libmspack 0.2alpha and wxWidgets 2.8.11 (unicode version)

My distro: Slackware 13.1 (updated to current)

Steps to reproduce:
(I checked this on 2 machines)

1) launch kicad under wmii
2) launch eeschema (schematic editor), or pcbnew (pcb editor)

block selection is broken in both eeschema and pcbnew (You can click and
drag and nothing happens)

Problem is gone after switching to dwm, fluxbox or xfce (I did not test
other WMs)

I switched to dwm so far, but I would like to continue using wmii as my WM.

I will be gone for 20 days from tomorrow (vacation, no internet access),
so You won't get any replies from me until I'm back :)


What version of wmii are you using? For me, block selection 
works exactly the same in wmii, windowlab, and dwm.




--
Kris Maglione

It is hard enough to remember my opinions, without also remembering my
reasons for them.
--Friedrich Wilhelm Nietzsche

Re: [dev] Suckless design in Games

[Robert Ransom]

On Wed, 11 Aug 2010 11:19:37 +0200
lordkrandel  wrote:

> > A computer game is a computer program whose creator intended primarily
> > that human beings enjoy interacting with it.
> 
> I was just arguing that the idea of "suckless design" may fit not so 
> well in game programming.

That depends on what the game's target audience enjoys.


I cease to enjoy the Battle for Wesnoth when I have to manage well over
a dozen units each turn, by hand, with a lousy GUI, and I forget what I
was trying to *do* with each unit.

I think I would enjoy a game with the same logic, but with the ability
to set user-designed AIs for units and/or groups of units added to the
frontend.  The easiest way to allow that is probably to chop the GUI
out of the game client and connect the two using a well-designed,
well-specified protocol (preferably built on 9P).  That would have the
side effect of moving BfW slightly closer to the ‘suckless’ ideal.
(Not noticeably closer, though; have you *seen* its WML data format?)


If designed and implemented properly, a game can be quite suckless, and
still have an interface that mainstream gamers (I know, that sounds
like an oxymoron) enjoy interacting with.

A suckless game should make interfaces that other audiences would enjoy
easy to add, whether that is part of the definition of ‘suckless’ or
just a side effect.


> That's why at a certain point I answered a message in a private way
> but then the reply came on the mailing list. Sorry for the "crap".

I'm glad you aren't one of those professional philosophers (they
*would* ask for more precise definitions of “neurologist” and
“dopamine”).

Your message was not crap, and objectively defining “to be fun” (by
defining “to enjoy”; an activity is fun if the animals participating in
it enjoy it) was probably useful, but I do NOT want to go one step
beyond that down the road of trying to precisely define everyday words
in terms of other words -- the sophists have done enough damage to
society with their word games already.


>  > To the extent that this list has a topic, it seems to be ‘the
>  > philosophy  of computer programming’.  That does not mean that any of
>  > us want to read the kind of crap [that *is* a noun, right?] that
>  > university departments of Philosophy emit.
> 
> Suckless dev also means discussing about what "suckless design" is.

Good point, although I consider that an aspect of the philosophy of
computer programming.

We're never going to agree on how to define “suckless design”, but
it'll be fun to try to find out what it means.  (Through heated
discussion, of course.)


> I'll never quit saying: If you are not interested, do not read, do not
> reply.

I am interested in discussing useful philosophy.  I am also very
interested in keeping “grue” and “bleen” off this list.  (For those of
you who have not been exposed to that bit of modern sophistry, “grue”
does not refer to the monsters in Zork here.)


> I'll get back when I have a -n lines patch so you will all be happy.

???

Code size isn't the only measure of complexity.  Sometimes, one program
needs to be made larger in order to keep the complexity of a larger
system down.


Let's start another flame war:

I think pacman (the Arch Linux package manager) is too simple to manage
packages well.  Seriously.


Robert Ransom


signature.asc
Description: PGP signature

Re: [dev] off topic - awk versions performance comparison

[Kris Maglione]

On Wed, Aug 11, 2010 at 06:14:55AM -0400, Joseph Xu wrote:

Hi everyone,

I was playing around with awk and ran into some surprising data for the  
function match(s, r), which returns the position of the first match of  
regular expression r in string s. Here's the test I ran:


$ yes | head -1 | tr -d '\n' >/tmp/big
$ yes | head -100 | tr -d '\n' >/tmp/bigger
$ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big

real0m0.056s
user0m0.053s
sys 0m0.000s
$ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger

real0m5.695s
user0m5.140s
sys 0m0.553s

The difference is almost exactly 100x, which is the size difference  
between the input files. It seems ridiculous that the amount of time  
taken to match the first character of a string grows linearly with the  
size of the string. The time it takes to load the contents of the file  
does not contribute significantly to this increase.


You don't make sense. The second test performs the match two 
orders of magnitude more times, so it should be two orders of 
magnitude slower. It's not comparing a single string that is 100 
times as long, but rather running the same test 100 times for 
either 10⁴ or 10⁶ identical strings.


Finally, trying Kernighan's One True Awk (from  
http://www.cs.princeton.edu/~bwk/btl.mirror/awk.tar.gz)


This is the same as p9p's awk, except perhaps for some relative 
minor changes to one or the other over recent years.


So at least nawk's performance makes sense. To make things a little more  
confusing, I tried matching on a non-existent pattern:


It does only if the pattern match takes about 1/10th of a 
millisecond, which it's beyond the granularity of your shell's 
time function to determine.


--
Kris Maglione

Lovers of problem solving, they are apt to play chess at lunch or
doodle in algebra over cocktails, speak an esoteric language that some
suspect is just their way of mystifying outsiders.  Deeply concerned
about logic and sensitive to its breakdown in everyday life, they
often annoy friends by asking them to rephrase their questions more
logically.
--Time Magazine in 1965

Re: [dev] off topic - awk versions performance comparison

[Robert Ransom]

On Wed, 11 Aug 2010 06:41:30 -0400
Kris Maglione  wrote:

> On Wed, Aug 11, 2010 at 06:14:55AM -0400, Joseph Xu wrote:
> > Hi everyone,
> >
> > I was playing around with awk and ran into some surprising data for the  
> > function match(s, r), which returns the position of the first match of  
> > regular expression r in string s. Here's the test I ran:
> >
> > $ yes | head -1 | tr -d '\n' >/tmp/big
> > $ yes | head -100 | tr -d '\n' >/tmp/bigger
> > $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big
> >
> > real0m0.056s
> > user0m0.053s
> > sys 0m0.000s
> > $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger
> >
> > real0m5.695s
> > user0m5.140s
> > sys 0m0.553s
> >
> > The difference is almost exactly 100x, which is the size difference  
> > between the input files. It seems ridiculous that the amount of time  
> > taken to match the first character of a string grows linearly with the  
> > size of the string. The time it takes to load the contents of the file  
> > does not contribute significantly to this increase.
> 
> You don't make sense. The second test performs the match two 
> orders of magnitude more times, so it should be two orders of 
> magnitude slower. It's not comparing a single string that is 100 
> times as long, but rather running the same test 100 times for 
> either 10⁴ or 10⁶ identical strings.

No, he stripped out the newlines with tr.


Robert Ransom


signature.asc
Description: PGP signature

Re: [dev] off topic - awk versions performance comparison

[Kris Maglione]

On Wed, Aug 11, 2010 at 04:01:27AM -0700, Robert Ransom wrote:

On Wed, 11 Aug 2010 06:41:30 -0400
Kris Maglione  wrote:


On Wed, Aug 11, 2010 at 06:14:55AM -0400, Joseph Xu wrote:
> Hi everyone,
>
> I was playing around with awk and ran into some surprising data for the  
> function match(s, r), which returns the position of the first match of  
> regular expression r in string s. Here's the test I ran:

>
> $ yes | head -1 | tr -d '\n' >/tmp/big
> $ yes | head -100 | tr -d '\n' >/tmp/bigger
> $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big
>
> real0m0.056s
> user0m0.053s
> sys 0m0.000s
> $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger
>
> real0m5.695s
> user0m5.140s
> sys 0m0.553s
>
> The difference is almost exactly 100x, which is the size difference  
> between the input files. It seems ridiculous that the amount of time  
> taken to match the first character of a string grows linearly with the  
> size of the string. The time it takes to load the contents of the file  
> does not contribute significantly to this increase.


You don't make sense. The second test performs the match two 
orders of magnitude more times, so it should be two orders of 
magnitude slower. It's not comparing a single string that is 100 
times as long, but rather running the same test 100 times for 
either 10⁴ or 10⁶ identical strings.


No, he stripped out the newlines with tr.


He might have, if he used GNU tr. However, in that case, my 
results are nowhere as dramatic as his.


--
Kris Maglione

There are two ways to write error-free programs; only the third works.
--Alan J. Perlis

Re: [dev] Suckless design in Games

[Szabolcs Nagy]

* Chidambaram Annamalai  [2010-08-11 13:12:46 +0530]:
> Have you even bothered to look through the sources? You really have
yes
although it was a couple of years ago last time i used bgl

> to decouple the storage schemes from the algorithms so that you can write
> O(M + N) code to support O(M*N) template instances. And there is no point if
> this abstraction had a severe penalty on the runtime performance. BGL
> exactly knows which algorithm to use for a particular storage mode because
> intelligence is built into it using traits. The hierarchial design (which is
this is a misconception about bgl and c++ generic programming in general

you can treat certain aspects of the algorithms but not everything
genericity is only available where the designers thought about it
(eg you cannot reuse a stack in dfs graph traversals of various graphs
because it is hardcoded in boost)

this usually ends up in a lot of configurability where users don't
need it, but the result is still not flexible enough for practical
problems

that's why everyone ends up implementing their own containers instead
of using stl in a bigger c++ project
(eg by adding concurrency support or using different tradeoffs in the
algorithm design, so eventhough stl is very generic it is still not
flexible enough)

intuition tells that generic code allows easy replacement of components
but this is a fallacy:
- the designer must know how the code will be used in advance
and decompose the algorithms that way
- the users need to know a lot more about the internal implementation,
how an abstract component interacts with others
(the more fine grained the generic code the more difficult to use it)
(it's not true that you can easily write your own graph represantation
to use it with boost you need to know a lot of details)
(from the docs a lot of semantic detail is not clear, eg can you modify
a graph from a visitor? boost uses iterators and in many datastructure
modifications invalidates them)
- when an algorithm is used in the most simple and usual way, genericity
causes a lot of unnecessary boilerplate, confusion about the api, and
cryptic compiler error messages
(to find the shortest path in a simple directed graph with int edge
weights, i still have to fill the template arguments
http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp
this is not elegant code)

i experimented with various types of genericity for algorithms
here is one approach:
implement the algorithm in the simplest way for the most useful types
etc. then when you need it for a specific task then copy the code and
apply appropriate modifications in the source (often s/type1/type2/g)

it turns out that with this approach it's often easier to change
a component without screwing things up than by understanding all
the gory details of a generic api like boost

adapting an algorithm for your usecase usually takes less than an hour
and the result is readable customized code, easy to debug, easy to edit

> Template metaprogramming uses static polymorphism which is an entirely
> different beast from OO inheritance that uses dynamic polymorphism.
yes, each of them has quirks and the user of the library should deal
them
(using various concepts together the complexity of the result is the
product of the complexity of each part, not the sum)

my argument is that this amount of abstraction just not worth the effort
(at least in c++)

Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)

[Connor Lane Smith]

> 4.2 should be released soon, yes. The code affected probably won't be
> changed at all between now and then, so the patch shouldn't get
> rejected.

That was a lie. The patch fails as of r357.

cls

Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)

[StephenB]

On 11 August 2010 14:25, Connor Lane Smith  wrote:
>
> That was a lie. The patch fails as of r357.

I'm sure it will be easy to fix, I'll have a look later tonight, as well as
pushing it to the wiki.

StephenB

Re: [dev] Suckless design in Games

[Eivind Michael Skretting]

On Wed, Aug 11, 2010 at 10:32:15AM +0200, Antoni Grzymala wrote:
> > I hope you aren't suggesting that Mozart *is* minimalist.
> 
> He most definitely is (along with Chopin, I'd argue) – at the opposite
> end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday.

Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's
pieces are maybe light (but not all of them, like Don Giovanni or Kyrie
Eleison from Requiem), and Chopin may be elegant, but Minimalism is a
seperate genre of music, represented by composers like John Adams, Steve
Reich and Philip Glass. 

One of the big differences is the theme development, Minimalists use
none of the classical forms of Mozart or Chopin, but rather a repetitive
form of slow progression. 

No flames, just information :)


Eivind

Re: [dev] Suckless design in Games

[Anh Hai Trinh]

On Wed, Aug 11, 2010 at 9:13 PM, Eivind Michael Skretting
 wrote:
>
> Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's
> pieces are maybe light (but not all of them, like Don Giovanni or Kyrie
> Eleison from Requiem), and Chopin may be elegant, but Minimalism is a
> seperate genre of music, represented by composers like John Adams, Steve
> Reich and Philip Glass.
>
> One of the big differences is the theme development, Minimalists use
> none of the classical forms of Mozart or Chopin, but rather a repetitive
> form of slow progression.


You are technically right, but this "minimalism" is nothing more than
a name tag.

Opponents of Steve Reich & Philip Glass may say their music has
needless repetitions.

To contrast, consider Bach's Chaconne: "On one stave, for a small
instrument, the man writes a whole world of the deepest thoughts and
most powerful feelings." Is this a minimalist piece, even when it's
15min long? As a former composition student, I would say it is.

I think the essence of minimalism is that one take away as much as one
possibly can.

It's interesting that in this meaning, minimalism is not just the
opposite of bloat, but also denotes some kind of balance.


-- 
@chickamade

Re: [dev] Suckless design in Games

[Connor Lane Smith]

On 11 August 2010 15:35, Anh Hai Trinh  wrote:
> I think the essence of minimalism is that one take away as much as one
> possibly can.
>
> It's interesting that in this meaning, minimalism is not just the
> opposite of bloat, but also denotes some kind of balance.

"The simplicity of wabi-sabi is best described as the state of grace
arrived at by a sober, modest, heartfelt intelligence. The main
strategy of this intelligence is economy of means. Pare down to the
essence, but don’t remove the poetry. Keep things clean and
unencumbered, but don’t sterilize. (Things that are wabi-sabi are
emotionally warm, never cold.) Usually this implies a limited palette
of materials. It also means keeping conspicuous features to a minimum.
But it doesn’t mean removing the invisible connective tissue that
somehow binds the elements into a meaningful whole."
-- Leonard Koren

It seemed appropriate, and I just adore that quote.

cls

Re: [dev] Suckless design in Games

[Connor Lane Smith]

On 11 August 2010 05:28, Alex Hutton  wrote:
> Thanks, join looks very useful. Actually a while ago I was talking to
> some web developer friends and I was talking about writing a CMS that
> uses flat files and no databases, but they thought I was crazy...
> don't know why I've started to conform to the database crowd :).
> Though from looking at sqlite it is not as overly complex as other
> systems; the whole database can be loaded into memory and there's no
> 'database server'.

Databases are all too often used when flat files would do. Only in
certain circumstances do a database's benefits outweigh its overhead.
You are right, though - if you do have to use a relational database,
SQLite is often the way to go.

cls

Re: [dev] Suckless design in Games

[David Tweed]

On Wed, Aug 11, 2010 at 1:05 PM, Szabolcs Nagy  wrote:
> i experimented with various types of genericity for algorithms
> here is one approach:
> implement the algorithm in the simplest way for the most useful types
> etc. then when you need it for a specific task then copy the code and
> apply appropriate modifications in the source (often s/type1/type2/g)
>
> it turns out that with this approach it's often easier to change
> a component without screwing things up than by understanding all
> the gory details of a generic api like boost
>
> adapting an algorithm for your usecase usually takes less than an hour
> and the result is readable customized code, easy to debug, easy to edit

I spent a while working for a company that used that philosphy (albeit
in Matlab). As someone who didn't write the original algorithms (so I
didn't have the slowly accumulated knowledge from having been the one
who wrote them) it was a complete nightmare because there were various
implementations of a basic algorithm, all different subsets of the
bugs that had ever existed in the algorithm development depending on
when and who they'd branched from. Worse, once this had been done for
a while the using code sometimes grew to depend on some of the "bugs"
(rather than biting the bullet and consolidating them and dealing with
the fallout) so you had to basically keep in mind what peculiarities
this particular implementation of the algorithm had (which of course
was always from memory because even in this case, the original code
writers frown on you putting comments about what bugs their code has).
And of course, because "if you can't see that the code has broken,
don't poke it" when a bug was fixed in one implementation the other
implementations weren't checked whilst memories were fresh. Unified
implementations would have required more up-front work, but would I
think have been less work overall. (The people who had actually
written the rats maze of code disagreed; it's difficult to see how
much was partly because it was their baby.)

All of your points have some validity, but given the choice between
one algorithm implementation with a complex BUT EXPLICIT API and
multiple "implementations of some algorithm that does something along
these lines" with simple APIs, personally I'd take the one
implementation.

-- 
cheers, dave tweed__
computer vision reasearcher: david.tw...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Re: [dev] Suckless design in Games

[Connor Lane Smith]

On 10 August 2010 22:56, Chidambaram Annamalai  wrote:
> I suppose you have browsed through the sources an don't find anything novel
> in them. In which case, I certainly would like to know what you consider
> elegant. Then, maybe I can learn to appreciate good design?

I haven't even heard of Boost until now, and I don't know C++, but I
have looked at some elegant, and a lot of not-so-elegant, code. I used
to consider Plan 9 to be elegant, but as I've grown more familiar with
the source behind the concepts, I'm not quite so sure anymore.
(Heretic!)

Amongst my most admired code is xv6[1], a modern x86 reimplementation
of UNIX V6 by Russ Cox, Frans Kaashoek, and Robert Morris. Having
hacked around with the source while I was writing my own kernel, I
have to say, it really is beautiful. (A lot of credit must go to Ken
Thompson, Dennis Ritchie, et al for the original V6, of course.)

cls

[1]: http://pdos.csail.mit.edu/6.828/xv6/

Re: [dev] Suckless design in Games

[Eivind Michael Skretting]

On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote:
> I think the essence of minimalism is that one take away as much as one
> possibly can.
> 

Then one should exclude Chopin from that definition. In regard to the
"needless repetitions" of Reich and Glass, that is much of what the
style is about. The music is more about structures and patterns than
melody and harmony. 

On a end note, the original mention of Minimalism was with a capital
"M", so I figured the discussion needed some clearing-up.

Eivind

Re: [dev] Suckless design in Games

[Anh Hai Trinh]

On Wed, Aug 11, 2010 at 10:08 PM, Eivind Michael Skretting
 wrote:
> On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote:
>> I think the essence of minimalism is that one take away as much as one
>> possibly can.
>>
>
> Then one should exclude Chopin from that definition.

What do you mean exactly? His A major Prelude is probably the shortest
piece of music that exists (20~ seconds) and amongst the most
beautiful. If that is not minimalistic, I don't know what is. Chopin
is, after all, most famous for his _miniature_ pieces.

> On a end note, the original mention of Minimalism was with a capital
> "M", so I figured the discussion needed some clearing-up.

Point taken.


-- 
@chickamade

Re: [dev] Suckless design in Games

[Antoni Grzymala]

Eivind Michael Skretting dixit (2010-08-11, 16:13):

> > He most definitely is (along with Chopin, I'd argue) – at the opposite
> > end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday.
> 
> Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's
> pieces are maybe light (but not all of them, like Don Giovanni or Kyrie
> Eleison from Requiem), and Chopin may be elegant, but Minimalism is a
> seperate genre of music, represented by composers like John Adams, Steve
> Reich and Philip Glass. 
>   
> One of the big differences is the theme development, Minimalists use
> none of the classical forms of Mozart or Chopin, but rather a repetitive
> form of slow progression. 
> 
> No flames, just information :)

I'm well aware of the style represented by Reich, Glass et al., however:

Anh Hai Trinh dixit (2010-08-11, 21:35):

> You are technically right, but this "minimalism" is nothing more than
> a name tag.
> 
> Opponents of Steve Reich & Philip Glass may say their music has
> needless repetitions.
> 
> To contrast, consider Bach's Chaconne: "On one stave, for a small
> instrument, the man writes a whole world of the deepest thoughts and
> most powerful feelings." Is this a minimalist piece, even when it's
> 15min long? As a former composition student, I would say it is.
> 
> I think the essence of minimalism is that one take away as much as one
> possibly can.

And this is exactly the essence of Chopin's music – absolute necessary
minimum (with regards to the style and the times around which Chopin's
work was created, perhaps you have to get to know Chopin's music quite
well to actually appreciate this). Quoting Antoine de Saint-Exupéry:

„Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.”

Which could easily be said about Chopin's music as much as Bach and
Mozart (taking into account different stylistic
considerations). Though the two latter are probably not as even in
high-quality work (see below).

Anh Hai Trinh dixit (2010-08-11, 22:29):

> >> I think the essence of minimalism is that one take away as much as one
> >> possibly can.
> >>
> >
> > Then one should exclude Chopin from that definition.

Definitely not!

> What do you mean exactly? His A major Prelude is probably the shortest
> piece of music that exists (20~ seconds) and amongst the most
> beautiful. If that is not minimalistic, I don't know what is. Chopin
> is, after all, most famous for his _miniature_ pieces.

I would argue about that: the mid-sized Impromptus, Ballades, Fantaise
and Barcarolle (and the lateish-largish Mazurkas and Nocturnes) are
probably his best works, but the entire published (by him) body of
work is of such high quality, that it's pretty difficult to discuss
which particular works are “best”.

As to the “shortest piece ever written contest”, I'm certain there are
lots others, a tiny e-flat-minor prelude (about three lines) by
Scriabin immediately springs to mind. Almost Haiku (if not for the
late romantic style :)).

> > On a end note, the original mention of Minimalism was with a capital
> > "M", so I figured the discussion needed some clearing-up.
> 
> Point taken.

Yeah, I just had a knee-jerk reaction to “Mozart *not* being
minimalist” (without the capital “M”), which in my opinion, and by the
above account he certainly is.

-- 
[a]

Re: [dev] Suckless design in Games

[Eivind Michael Skretting]

On Wed, Aug 11, 2010 at 10:29:18PM +0700, Anh Hai Trinh wrote:
> On Wed, Aug 11, 2010 at 10:08 PM, Eivind Michael Skretting
>  wrote:
> > On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote:
> >> I think the essence of minimalism is that one take away as much as one
> >> possibly can.
> >>
> >
> > Then one should exclude Chopin from that definition.
> 
> What do you mean exactly? His A major Prelude is probably the shortest
> piece of music that exists (20~ seconds) and amongst the most
> beautiful. If that is not minimalistic, I don't know what is. Chopin
> is, after all, most famous for his _miniature_ pieces.

Well, first of all, as have been mentioned, it's not about lenght.
And Chopin's harmonies is in no way minimalistic (meaning "simple"), and 
all the trills and (argh, don't remember the english word...
lots-of-tones) is more the work of a piano virtuoso than a
"minimalistic" composer. He did, after all, write things down like he
played it, which resultet in different editions to different
publishers, in the same period of time!

Well, isn't this a fun discussion to have in a programmer's mailing list :)

Eivind

[dev] three column layout / getting started writing patches

[Jaime Villarreal]

Hi there.
I have a special project for which I'd like to patch dwm to function with a
3 column layout.
I'd like to have one wide column in the center (ideally this would be the
master column), and two skinnier columns to the right and left. The first
three clients to open should occupy these three columns and any additional
clients could stack to the right or left or even in the center column,
doesn't really matter as I will never really open any more than three
clients for this application.

I've been using dwm for over a year now and I'm very happy with it. While
I've had a lot of fun writing bash scripts to update the status bar up until
now I've yet to writing my own patch. I've skimmed over the code and it was
not immediately obvious to me what was going on. I was hoping that someone
on the list would be willing to point me towards some more documentation,
code snippets, commented code or examples.

Thanks in advance!

Re: [dev] Suckless design in Games

[Anh Hai Trinh]

On Wed, Aug 11, 2010 at 11:20 PM, Eivind Michael Skretting
 wrote:
>>
>> What do you mean exactly? His A major Prelude is probably the shortest
>> piece of music that exists (20~ seconds) and amongst the most
>> beautiful. If that is not minimalistic, I don't know what is.
>
> Well, first of all, as have been mentioned, it's not about lenght.

Email me off-list about this if you want to discuss this point further
but no matter what angle you look at this piece, there is just no way
it is not minimalistic.

> And Chopin's harmonies is in no way minimalistic (meaning "simple").

Not for that particular piece. In general, nowadays, Chopin's harmony
is considered to be in the Common Practice Period and are well
understood by second-semester harmony students. It is not simple, but
certainly not complex. Chopin's harmony to a music student is like a
heap to a programmer. (obviously this is just a way of saying)


-- 
@chickamade

Re: [dev] Suckless design in Games

[Anh Hai Trinh]

On Wed, Aug 11, 2010 at 11:06 PM, Antoni Grzymala  wrote:
>
> I would argue about that: the mid-sized Impromptus, Ballades, Fantaise
> and Barcarolle (and the lateish-largish Mazurkas and Nocturnes) are
> probably his best works, but the entire published (by him) body of
> work is of such high quality, that it's pretty difficult to discuss
> which particular works are “best”.

The ballades are quite unique, but the rest you mention is a bit of
bloat to me. Chopin sucks at larger forms. If the only Chopin
collection to survive is the Preludes, I would still consider him top
notch. I believe I'm not alone on this position.

minimalism ftw!

-- 
@chickamade

Re: [dev] Suckless design in Games

[Eivind Michael Skretting]

On Thu, Aug 12, 2010 at 12:08:13AM +0700, Anh Hai Trinh wrote:
> On Wed, Aug 11, 2010 at 11:20 PM, Eivind Michael Skretting
>  wrote:
> >>
> >> What do you mean exactly? His A major Prelude is probably the shortest
> >> piece of music that exists (20~ seconds) and amongst the most
> >> beautiful. If that is not minimalistic, I don't know what is.
> >
> > Well, first of all, as have been mentioned, it's not about lenght.
> 
> Email me off-list about this if you want to discuss this point further
> but no matter what angle you look at this piece, there is just no way
> it is not minimalistic.
> 
> > And Chopin's harmonies is in no way minimalistic (meaning "simple").
> 
> Not for that particular piece. In general, nowadays, Chopin's harmony
> is considered to be in the Common Practice Period and are well
> understood by second-semester harmony students. It is not simple, but
> certainly not complex. Chopin's harmony to a music student is like a
> heap to a programmer. (obviously this is just a way of saying)

Well, just to finish, I am a music student, so I do know what I am
talking about, and that it's complexity is a matter of what it's
compared to (I think I understand Chopin's harmony better than heaps, by
the way).

Thanks for the argument, anyway!

Eivind 

Re: [dev] Suckless design in Games

[Chidambaram Annamalai]

> > to decouple the storage schemes from the algorithms so that you can write
> > O(M + N) code to support O(M*N) template instances. And there is no point
> if
> > this abstraction had a severe penalty on the runtime performance. BGL
> > exactly knows which algorithm to use for a particular storage mode
> because
> > intelligence is built into it using traits. The hierarchial design (which
> is
> this is a misconception about bgl and c++ generic programming in general
>
> you can treat certain aspects of the algorithms but not everything
> genericity is only available where the designers thought about it
> (eg you cannot reuse a stack in dfs graph traversals of various graphs
> because it is hardcoded in boost)
>
> this usually ends up in a lot of configurability where users don't
> need it, but the result is still not flexible enough for practical
> problems
>

I really haven't used bgl in any serious way like a project or so. So maybe
what you're saying is true.

BGL's flexbility might become a problem in itself as it requires knowing so
much that, it becomes a library by experts and for experts. This is a rather
unfortunate outcome. I am far from a language expert but I think such
problems arise because syntactically C++ does not provide sufficient
flexibility for expressing abstractions without writing extensive amounts of
code to make it abundantly clear as to what you're trying to do.


that's why everyone ends up implementing their own containers instead
> of using stl in a bigger c++ project
> (eg by adding concurrency support or using different tradeoffs in the
> algorithm design, so eventhough stl is very generic it is still not
> flexible enough)
>
> intuition tells that generic code allows easy replacement of components
> but this is a fallacy:
> - the designer must know how the code will be used in advance
> and decompose the algorithms that way
> - the users need to know a lot more about the internal implementation,
> how an abstract component interacts with others
> (the more fine grained the generic code the more difficult to use it)
> (it's not true that you can easily write your own graph represantation
> to use it with boost you need to know a lot of details)
> (from the docs a lot of semantic detail is not clear, eg can you modify
> a graph from a visitor? boost uses iterators and in many datastructure
> modifications invalidates them)
> - when an algorithm is used in the most simple and usual way, genericity
> causes a lot of unnecessary boilerplate, confusion about the api, and
> cryptic compiler error messages
> (to find the shortest path in a simple directed graph with int edge
> weights, i still have to fill the template arguments
>
> http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp
> this is not elegant code)
>

You have a point here. I have written python code during my graph theory
course to implement algorithms on graphs and they turned out to be
remarkably clear and concise. I recall that being able to use dictionaries
to implement the adjacency lists and the lack of strong typing requirements
led to very readable code. Here's one that computes the all paths between
two vertices in a directed graph:

 #!/usr/bin/env python
graph = {'A': ['B', 'C'],
 'B': ['C', 'D'],
 'C': ['D'],
 'D': ['C'],
 'E': ['F'],
 'F': ['C']}

def find_all_paths(G, start, end, visited = []) :
for i in G[start] :
if i not in visited :
if i == end :
yield [start] + [i]
else :
for j in find_all_paths(G, i, end, visited + [start]) :
yield [start] + j

start, end = 'A', 'D'
for i in find_all_paths(graph, start, end):
print i


i experimented with various types of genericity for algorithms
> here is one approach:
> implement the algorithm in the simplest way for the most useful types
> etc. then when you need it for a specific task then copy the code and
> apply appropriate modifications in the source (often s/type1/type2/g)
>
> it turns out that with this approach it's often easier to change
> a component without screwing things up than by understanding all
> the gory details of a generic api like boost
>
> adapting an algorithm for your usecase usually takes less than an hour
> and the result is readable customized code, easy to debug, easy to edit
>

I had written some C code for a programming assignment and my experiences
parallel what you describe here. It had no dependencies on external
libraries and everything was done from scratch (ok that wasn't a choice I
had -- assignment remember :)). It turned out to be fairly simple to
implement and use and most importantly maintain. I can go back to the code
today and still understand most things quickly.



> > Template metaprogramming uses static polymorphism which is an entirely
> > different beast from OO inheritance that uses dynamic polymorphism.
> yes, each of them has quirks and the user of the

Re: [dev] Suckless design in Games

[Chidambaram Annamalai]

On Wed, Aug 11, 2010 at 8:37 PM, Connor Lane Smith  wrote:

> On 10 August 2010 22:56, Chidambaram Annamalai 
> wrote:
> > I suppose you have browsed through the sources an don't find anything
> novel
> > in them. In which case, I certainly would like to know what you consider
> > elegant. Then, maybe I can learn to appreciate good design?
>
> I haven't even heard of Boost until now, and I don't know C++, but I
> have looked at some elegant, and a lot of not-so-elegant, code. I used
> to consider Plan 9 to be elegant, but as I've grown more familiar with
> the source behind the concepts, I'm not quite so sure anymore.
> (Heretic!)
>

Interesting. May I ask what languages you are familiar with?



> Amongst my most admired code is xv6[1], a modern x86 reimplementation
> of UNIX V6 by Russ Cox, Frans Kaashoek, and Robert Morris. Having
> hacked around with the source while I was writing my own kernel, I
> have to say, it really is beautiful. (A lot of credit must go to Ken
> Thompson, Dennis Ritchie, et al for the original V6, of course.)
>

Thanks for pointing me to beautful code! I will definitely take a look at
this.


Chillu

Re: [dev] off topic - awk versions performance comparison

[Joseph Xu]

On 08/11/2010 07:10 AM, Kris Maglione wrote:
> On Wed, Aug 11, 2010 at 04:01:27AM -0700, Robert Ransom wrote:
>> On Wed, 11 Aug 2010 06:41:30 -0400
>> Kris Maglione  wrote:
>>
>>> On Wed, Aug 11, 2010 at 06:14:55AM -0400, Joseph Xu wrote:
 Hi everyone,

 I was playing around with awk and ran into some surprising data for the  
 function match(s, r), which returns the position of the first match of  
 regular expression r in string s. Here's the test I ran:

 $ yes | head -1 | tr -d '\n' >/tmp/big
 $ yes | head -100 | tr -d '\n' >/tmp/bigger
 $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/big

 real0m0.056s
 user0m0.053s
 sys 0m0.000s
 $ time awk '{for (i=1; i < 100; i++) { match($0, "y")} }' /tmp/bigger

 real0m5.695s
 user0m5.140s
 sys 0m0.553s

 The difference is almost exactly 100x, which is the size difference  
 between the input files. It seems ridiculous that the amount of time  
 taken to match the first character of a string grows linearly with the  
 size of the string. The time it takes to load the contents of the file  
 does not contribute significantly to this increase.
>>>
>>> You don't make sense. The second test performs the match two 
>>> orders of magnitude more times, so it should be two orders of 
>>> magnitude slower. It's not comparing a single string that is 100 
>>> times as long, but rather running the same test 100 times for 
>>> either 10⁴ or 10⁶ identical strings.
>>
>> No, he stripped out the newlines with tr.
> 
> He might have, if he used GNU tr. However, in that case, my 
> results are nowhere as dramatic as his.
> 

I was using GNU tr. The input files were single lines with 1 or 100 
y's, so I was doing 100 matches in each case (from the for loop) on the same 
line. I guess I should have made that more explicit, sorry. I'm interested in 
what results you're getting.

Re: [dev] three column layout / getting started writing patches

[Valentin]

On Wed, Aug 11, 2010 at 11:59:06AM -0500, Jaime Villarreal wrote:
> Hi there.
> I have a special project for which I'd like to patch dwm to function with a
> 3 column layout.
> I'd like to have one wide column in the center (ideally this would be the
> master column), and two skinnier columns to the right and left. The first
> three clients to open should occupy these three columns and any additional
> clients could stack to the right or left or even in the center column,
> doesn't really matter as I will never really open any more than three
> clients for this application.

Try the attached function, a quick hack of the normal tile() layout.
After the first window, the next alternate between the right and left
stack.

--Valentin


pgpg2w5iWgXmm.pgp
Description: PGP signature

Re: [dev] three column layout / getting started writing patches

[Valentin]

Forgot attaching the file...
void
tcl(Monitor *m) {
	int x, h, w, mw;
	unsigned int i, n;
	Client *c;

	for(n = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), n++);
	if(n == 0)
		return;
	/* master */
	c = nexttiled(m->clients);
	mw = m->mfact * m->ww;
	resize(c, n<3?m->wx:m->wx+(m->ww-mw)/2, m->wy, (n == 1 ? m->ww : mw) - 2 * c->bw, m->wh - 2 * c->bw, False);
	if(--n == 0)
		return;

	w=(m->ww-mw)/((n>1)+1);
	c = nexttiled(c->next);
	/* left stack, if it exists */
	if(n>1){
		x=m->wx;
		h=m->wh/(n/2);
		for(i = 0; c && inext), i++) {
			resize(c, x, m->wy+i*h, w, h, True);
		}
	}
	/* right stack */
	x=m->wx+((n>1)?(mw+m->ww)/2:mw);
	h=m->wh/((n+1)/2);
	for(i = 0; c; c=nexttiled(c->next), i++) {
		resize(c, x, m->wy+i*h, w, h, True);
	}
}


pgpjNvGgk1SHa.pgp
Description: PGP signature

Re: [dev] three column layout / getting started writing patches

[Jaime Villarreal]

That works perfectly. Thanks!

On Wed, Aug 11, 2010 at 7:07 PM, Valentin  wrote:

> Forgot attaching the file...
>

[dev] Lexers and parsers 2

[Maurí­cio CA]

Hi, all,

Some time ago, I asked your sugestions on what should be a parser
we could use for shell scripting:

  http://lists.suckless.org/dev/0908/0822.html

Now I would like to show you this tool I wrote. It does exactly
what was discussed in those messages, i.e., it's something like
yacc that can be used for shell scripting. I call it 'noam':

  http://bitbucket.org/mauricio/noam
  http://bitbucket.org/mauricio/noam/downloads

noam reads a grammar with rules associated to actions defined as
shell commands. As an example, this script (taken from current
documentation) implements a "plus only" calculator:

  #!/usr/bin/noam
  layout : /[[:space:]]+/ * ;
  number : /[0-9]+/ ;
  plus : /\+/ layout number {echo $3 > $OUTPUT} ;
  plus : plus layout number {echo $1 + $3 | bc > $OUTPUT} ;
  number : /\(/ layout plus layout /\)/ {echo $3 > $OUTPUT} ;
  main : layout number layout {echo Result: $2} ;

If you name it 'calc.noam' and type:

  echo '(+ 1 2 (+ 3 4) (+ 5 6) 7)' | calc.noam

you'll get:

  Result: 28

I've had a lot of fun with this, and hope it's useful to you.

Best,

Maurício