[dev] Re: [surf] PATCH for default directory path - really uncritical

2009-11-25 Thread Alexander Surma
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

2009-11-25 Thread Alexander Surma
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

2009-11-25 Thread Alexander Surma
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



Re: [dev] a suckless computer algebra system

2009-11-25 Thread Yoshi Rokuko
very good point hiro !

On Wed, Nov 25, 2009 at 01:36:30AM +0100, hiro wrote:
> In a suckless CAS consisting of multiple applications the apps are
> combined easily by definition.
> 
> On Tue, Nov 24, 2009 at 10:19 PM, Preben Randhol  wrote:
> > Of course you can make x applications that each solve a spesific
> > mathematical problem, but what a mess it creates when you have to
> > combine applications. I have work with such systems and the time wasted
> > in transfering data from one to the other is a big problem. Not to say
> > the errors this can introduce...
> >
> 



Re: [dev] a suckless computer algebra system

2009-11-25 Thread Anselm R Garbe
2009/11/24 Preben Randhol :
> On Fri, 20 Nov 2009 18:39:04 +
> Anselm R Garbe  wrote:
>
>> Why not? I think it should be possible to have very minimalist and
>> specialized CAS', they managed to do that in the 50s and 60s, why not
>> today?
>
> We are not living in the 50's nor 60's... If the suckless approach is to

Mankind was able to visit the moon based on these very simple systems
at the end of that era, but hasn't ever been since (the modern excuse
is lack of money, but I disagree). I don't think that they did
everything wrong in the past or that most of the past technology has
no value to learn from.

> because the source code gets bigger or more complex, then IMHO
> suckless approach is not the correct approach for CAS.
>
> CAS is used to solve a multitude of problems that
> you cannot define into a narrow problem space.
>
> Of course you can make x applications that each solve a spesific
> mathematical problem, but what a mess it creates when you have to
> combine applications. I have work with such systems and the time wasted
> in transfering data from one to the other is a big problem. Not to say
> the errors this can introduce...

I never said that a suckless CAS' main objective would be LOC. But I'd
say that a suckless CAS would create one program for each specific
mathematical problem and define a uniform interface to combine these
programs using pipes to solve a complex problem. This also has the
advantage that one can easily distribute and scale each of these
programs onto separate cpus or even servers and hence increase the
overall performance. I would say that Go sounds like an interesting
language to start such a project.

Cheers,
Anselm