Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Peter Olson]

> On January 25, 2016 at 5:54 PM Rainer Weikusat
>  wrote:

 [...]

> A related but IMHO more interesting set of questions could be:
> 
> 1. Should every trivial crap $someone ever implemented since 1978 end up
>in general purpose library just because $someone happend to have to
>power to put it into it?
> 
> 2. Should people be required to memoize every trivial crap $someone ever
>implemented since 1978 just because that someone happened to have to
>power to ...?
> 
> 3. Should people who consider themselves Very Superior Entities because
>the have memoized every trivial crap $someone ever ... and so on, be
>taken as seriously as they continuously demand?

It must be trivial crap because nobody ever made a programming error parsing
path names when they rolled their own routines for it.  Also: Windows and Mac
path names follow different rules.  Use the libraries.  I actually like the
example of Python's os.path library, which implements a unified set of portable
routines for manipulating path names.

Peter Olson

Off topic P.S.: memoize means something different from memorize, which you
clearly meant.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater (was: "Common knowledge?"-question)

[KatolaZ]

On Mon, Jan 25, 2016 at 12:23:01PM +, Rainer Weikusat wrote:
> KatolaZ  writes:
> 
> [...]
> 
> >  I still don't see the need for an internal buffer to print out a
> >  formatted string, to be honest :)
> 
> Everything in code can always be implemented in a number of different
> ways, hence, whatever the code ends up doing is "not really needed" ---
> it could have achieved the same in a different way.
> 
> In this case, the function is part of a 79 lines program whose main
> looks like this:
> 
> int main(int argc, char **argv)
> {
> char const *name;
> int status;
> 
> name = get_name(*argv);
> openlog(name, LOG_PID | LOG_PERROR, LOG_DAEMON);
> if (argc < 3) usage();
> 
> print_start(name, argv[1]);
> 
> switch (fork()) {
> case -1:
>   die(__func__, "fork");
> 
> case 0:
>   execvp(argv[2], argv + 2);
> 
>   syslog(LOG_ERR, "main: execvp: %m(%d)", errno);
>   _exit(1);
> }
> 
> wait();
> print_stop(status);
> 
> return 0;
> }
> 
> and whose purpose is to enable me to write
> 
> starting "unleashed VPN" \
>   daemon -n chdir / monitor -n qvpn ssh-vpn mes-pgsql 5000 unleashed 
> unleashed4
> 
> in an init script to get a 'start: ok (or failed)' message printed to
> file descriptor 2 with having to put two printf invocation around the
> start command. And in the context of that, using stdio for the sole
> purpose of performing a trivial string formatting operation seemed very
> inappropriate --- that's new-fangled, ill-thought out stuff supposed to
> make UNIX(*) easier to use by moron^WUCB students and who really needs
> that?

I did not dispute your preference for not using stdio, but the choice
to copy strings into internal buffers just to change one character and
spit them on stdout. And in fact my 6-lines proposal for doing exactly
the same was:

void another_print_start(char *name, char *what){   
  char c[3] = " :"; 

   c[2] = name[0] & ~0x20;  

write(2, c+2, 1);   
 write(2, name+1, 
strlen(name) -1);   
write(2, c, 2); 

 write(2, what, strlen(what));  
 }

You asked for comments, I commented that alloca was probably not
needed and potentially dangerous, and that you could achieve the same
with simpler code, but apparently you didn't like the comment :D


> 
> The program also contains a very nice example of why the post-increment
> operators is useful (and I means 'useful', not 'common because of
> mindless copying of example code'):
> 
> static char const *get_name(char const *arg0)
> {
> char const *n, *r;
> 
> n = r = arg0;
> while (*r) if (*r++ == '/') n = r;
> return n;
> }

That's pretty straight-forward C-programming, IMHO, but I agree that
it could be seen as interesting by a mor^H^H^Hstudent who approaches C
for the first time.

Peace, love and hacking.

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Hendrik Boom]

On Mon, Jan 25, 2016 at 01:47:46PM +0100, Didier Kryn wrote:
> Le 25/01/2016 13:23, Rainer Weikusat a écrit :
> > while (*r) if (*r++ == '/') n = r;
> 
> Does it mean
> 
> while (*r)
>   {
> if (*r == '/')
>   {
>n = r;
>r++;
> }
>   }
> 
> or
> 
> while (*r)
>   {
> if (*r == '/')
>   {
>r++;
>n = r;
> }
>   }

Neither.  The incrementation in the original is not condiitional on 
the rquality test.  Which means that in the original, n gets assigned
the address of the character *after* the last '/' found.

In the other versions you get an infinite loop as soon as you 
encounter a character that isn't '/'.

-- hendrik

> 
> 
> I think the second answer is the good one. It is more readable
> and less error-prone than your example and the compiler will produce
> exactly the same instructions. You don't need to do the work of the
> compiler; it does it better. Better concentrate on writing programs
> easier to read and less error-prone. These pre-increment and
> post-increment instructions should be deprecated - I already
> advocated that on this list, although it is not the place :-)
> 
> The reason why seasonned programmers prefer the kind of
> expression you wrote, with post-increment, is a perfect example of a
> style dictated by pure aesthetics. This an error I used to make when
> I was younger, but, with age and learning, I have found true reasons
> to do otherwise.
> 
> Didier
> 
> Didier
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Didier Kryn]

Le 25/01/2016 13:23, Rainer Weikusat a écrit :

 while (*r) if (*r++ == '/') n = r;


Does it mean

while (*r)
  {
if (*r == '/')
{
   n = r;
   r++;
}
  }

or

while (*r)
  {
if (*r == '/')
{
   r++;
   n = r;
}
  }


I think the second answer is the good one. It is more readable and 
less error-prone than your example and the compiler will produce exactly 
the same instructions. You don't need to do the work of the compiler; it 
does it better. Better concentrate on writing programs easier to read 
and less error-prone. These pre-increment and post-increment 
instructions should be deprecated - I already advocated that on this 
list, although it is not the place :-)


The reason why seasonned programmers prefer the kind of expression 
you wrote, with post-increment, is a perfect example of a style dictated 
by pure aesthetics. This an error I used to make when I was younger, 
but, with age and learning, I have found true reasons to do otherwise.


Didier

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Didier Kryn]

Le 25/01/2016 13:47, Didier Kryn a écrit :


while (*r)
  {
if (*r == '/')
{
   r++;
   n = r;
}
  }


It's not even that. A for loop would do it:

for (  ;  *r;  r++ )  n = r+1;


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[karl]

Didier Kryn:
> Le 25/01/2016 13:23, Rainer Weikusat a écrit :
> >  while (*r) if (*r++ == '/') n = r;
> 
>  Does it mean
> 
>  while (*r)
>{
>  if (*r == '/')
>   {
> n = r;
> r++;
>  }
>}
> 
> or
> 
>  while (*r)
>{
>  if (*r == '/')
>   {
> r++;
> n = r;
>  }
>}
> 
> 
>  I think the second answer is the good one. It is more readable and 
> less error-prone than your example and the compiler will produce exactly 
> the same instructions. You don't need to do the work of the compiler; it 
> does it better. Better concentrate on writing programs easier to read 
> and less error-prone. These pre-increment and post-increment 
> instructions should be deprecated - I already advocated that on this 
> list, although it is not the place :-)
> 
>  The reason why seasonned programmers prefer the kind of expression 
> you wrote, with post-increment, is a perfect example of a style dictated 
> by pure aesthetics. This an error I used to make when I was younger, 
> but, with age and learning, I have found true reasons to do otherwise.

Uhh. I do prefer the short version, it should be perfectly 
understandable to anyone versed in c. I do prefer code to not to spread 
out onto mult. lines as your example does, since the shorter version 
make it easier to see the whole surronding function, and that aids the 
understanding.

Inserting pairs of {}'s makes things less prone to questions about what 
goes where, but there is no need to state the obvious, and inserting 
more whitespace than necessary does not help.

Putting things that are closely related close and as in this case in 
one line, makes it easier to mentally think "basename" and move on.

///

I have written a similar thing myself

cmdline_pgm = strrchr(argv[0], '/');
if (cmdline_pgm == NULL) cmdline_pgm = argv[0];
else cmdline_pgm++;

It worked and I moved on. Should I do it again, I'd consider Rainers
code.

///

As for Rainers original question, his code is pretty understandable
for me except for the "&= 0x20", which forced me to think.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Rainer Weikusat]

Didier Kryn  writes:
> Le 25/01/2016 13:23, Rainer Weikusat a écrit :
>>  while (*r) if (*r++ == '/') n = r;
>
> Does it mean
>
> while (*r)
>   {
> if (*r == '/')
>   {
>n = r;
>r++;
> }
>   }
>
> or
>
> while (*r)
>   {
> if (*r == '/')
>   {
>r++;
>n = r;
> }
>   }
>
>
> I think the second answer is the good one. It is more readable and
> less error-prone than your example and

... doesn't work. r (for 'running pointer') needs to be incremented on
every iteration until it hits the end of the string. In case it
currently pointed to a '/', 'n' ('pointer to [start of] name') needs to
be set to the char behind the slash. As soons as *r == 0 aka !*r, n will
point to the char after the last slash in the original string, ie, to
the program name part of a program pathname.

This is even already 'optimized for simplicity' as gcc will (usually)
issue code to reload the char r points and thus, if this was supposed
'optimized', it really ought to be something like (all untested)

char const *r, *n;
int c;

n = r = arg0;
while (c = *r++) if (c == '/') n = r;

A multi-line version could look like this:

while (c = *r) {
++r;
if (c == '/') n = r;
}

Or, for people who think everything ought to be expressed as for-loop
because everything can be expressed as for-loop,

char const *r, *n;
int c0, c1;

for (n = r = arg0, c1 = 0; c0 = *r; r++) {
if (c1 == '/') n = r;
c1 = c0;
}

This is a nice progression from '[maybe unusal but] straight-forward' to
'conventional [& contorted]'.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Dr. Nikolaus Klepp]

Am Montag, 25. Januar 2016 schrieb Rainer Weikusat:
> "Dr. Nikolaus Klepp"  writes:
> 
> [...]
> 
> > What about making the source smaller and not the executable?
> >
> > static void print_start(char const *name, char const *what) {
> >  if (name[0]) fprintf("%c%s",name[0]&~0x20, name+1);
> >  fprintf(stderr, " %s: ",what);
> > }
> 
> Are you seriously convinced that - in 2016 - there are still people who
> haven't heard of the stdio library introduced with the 7th edition of
> UNIX(*)?

Well ... yes.

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Lightweight media/video player

[Mitt Green]

dev1fanboy wrote:


>One of the better ones for the purpose of keeping pulse and dbus out is xine
>(xine-ui).

It is ugly, wants over nine thousooond packages to be installed,
including samba-libs...

>A good music player is cmus which uses ncurses and has playlist support, does
>not use any crappy extra libs, no dbus or pulse.

cmus is cool, though I already use gmusicbrowser.



>mplayer2 has no dbus but does have libpulse0.

mplayer2 is fine, though I have no idea, why it needs many libs
(not so many as other do anyway) it looks minimalistic.
Probably will stick with it, thanks. I can't live without
libpulse0 anyway now, mostly because of
games (0 A.D., UT, RedEclipse etc., they all need it).




// Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Evolution of a Unix minimalist

[Mitt Green]

Removes GNOME3

Removes systemd

Removes Xfce
Removes 9wm

Removes X

Removes their package manager
Removes make, because "I can cc everything by myself"

Removes C++ programmes
Removes C programmes

"Why do I need Assembly when there is machine code"
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ad filtering and blocking

[dev1fanboy]

On Sunday, January 24, 2016 11:47 PM, Go Linux  wrote:
> 
> On Sun, 1/24/16, Ian Zimmerman  wrote:
> 
>  Subject: Re: [DNG] Ad filtering and blocking
>  To: dng@lists.dyne.org
>  Date: Sunday, January 24, 2016, 5:34 PM
> 
> On Sun, 1/24/16, Ian Zimmerman  wrote:
> 
> Subject: Re: [DNG] Ad filtering and blocking
> To: dng@lists.dyne.org
> Date: Sunday, January 24, 2016, 5:34 PM
> 
>>
>> The feature that was literally called "keep cookies until I close
>> iceweasel" (and still is, except that it doesn't work) was perfect.  Why
>> is it getting slowly dropped?  I don't know, but I'm guessing partly
>> because everyone uses bazillions of tabs :-(
>>
> 
> 
> 
> 
> Or maybe because xul is going the way of the dodo?

That's more likely, and there isn't much resistence on that yet.

> 
> http://forums.mozillazine.org/viewtopic.php?f=7=2979611
> 
> Have you tried an older version of that addon?
> 
> golinux
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd-free.org

[Jaromil]

re all,

here a new initiative by brothers and sisters of ArchLinux, one of the
first distributions to be bullied into systemd http://systemd-free.org

ArchLinux is a relatively young and very sharp distribution, they have
arguably the best documentation wiki on-line on GNU/Linux matters and
many smart people among their developers, some well known to us at
dyne.org.

This initiative is worth following I believe, especially for those of us
who are intentioned in stepping over to OpenRC, since that seems to be
the direction they are taking.

ciao

-- 
Denis Roio aka Jaromil   http://Dyne.org think  tank
  CTO and co-founder  free/open source developer
加密  6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ad filtering and blocking

[dev1fanboy]

Personally I had hoped that law would mean sites are discouraged from using 
cookies unless they are absolutely necessary, but that doesn't seem to be the 
case. I think sites are choosing to continue finding ways to annoy their users 
rather than just not using cookies where it's not necessary. On the other hand 
the EU has done something pretty stupid there easier to restrict what 
cookies can and cannot be used for than to force them to put banners on their 
site.

On Sunday, January 24, 2016 11:17 PM, Go Linux  wrote:
> On Sun, 1/24/16, da...@olansa.co.uk  wrote:
> 
>  Subject: Re: [DNG] Ad filtering and blocking
>  To: dng@lists.dyne.org
>  Date: Sunday, January 24, 2016, 1:18 PM
> 
>> Thanks for your reply. I am noticing that since some time ago websites
>> are starting to 'brainwash' users to use cookies. This is often done
>> by displaying a high contrast banner at the top threatening that by
>> using their website one MUST also enable cookies.
>>
>> Is there a way to avoid this new 'cool feature'?
>>
>> Edward
> 
> Edward, are these sites based in the EU? If it's very little to do with
> brainwashing -- at least by the site owners -- and everything to do with
> a cretinous law forcing EU-based sites to warn visitors of cookies.
> Apparently, at least according to the politicians who handed us this
> mess, cookies are the latest and greatest security threat to web users.
> More so than government intrusion, man in the middle attacks, forged
> site certificates, hacking or other such trivia. :)
> 
> Most sites are restricting themselves to a simple warning pop-up to
> comply with EU/national regulations (thus avoiding the remote threat of
> a prosecution) without getting in the way too much. Daft but true.
> 
> Cheers,
> 
> Dave H
> 
> 
> 
> I do a lot of custom element blocking in AdBlock which works very well -
> no popovers and/or overlays and or nag bars allowed here.  But sometimes I
> have to resort to stylish . . .
> 
> golinux
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Didier Kryn]

Le 25/01/2016 16:08, Rainer Weikusat a écrit :

Didier Kryn  writes:

Le 25/01/2016 13:23, Rainer Weikusat a écrit :

  while (*r) if (*r++ == '/') n = r;

 Does it mean

 while (*r)
   {
 if (*r == '/')
{
n = r;
r++;
 }
   }

or

 while (*r)
   {
 if (*r == '/')
{
r++;
n = r;
 }
   }


 I think the second answer is the good one. It is more readable and
less error-prone than your example and

... doesn't work. r (for 'running pointer') needs to be incremented on
every iteration until it hits the end of the string. In case it
currently pointed to a '/', 'n' ('pointer to [start of] name') needs to
be set to the char behind the slash. As soons as *r == 0 aka !*r, n will
point to the char after the last slash in the original string, ie, to
the program name part of a program pathname.

This is even already 'optimized for simplicity' as gcc will (usually)
issue code to reload the char r points and thus, if this was supposed
'optimized', it really ought to be something like (all untested)

char const *r, *n;
int c;

n = r = arg0;
while (c = *r++) if (c == '/') n = r;

A multi-line version could look like this:

while (c = *r) {
++r;
 if (c == '/') n = r;
}



It might be done with a for loop.  eg:

for ( ; *r ; ++r) if(*r=='/') n=r;
n++;

The for loop is the best construct for a loop with an incremental 
cursor. While is rather meant for things like


while ( (c=fgets(s, sizeof(s), stdin) )

At the end of the day, there are many ways to write even simple 
things :-)


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ad filtering and blocking

[Florian Zieboll]

On Sun, 24 Jan 2016 23:47:14 + (UTC)
Go Linux  wrote:


> Or maybe because xul is going the way of the dodo?
> 
> http://forums.mozillazine.org/viewtopic.php?f=7=2979611

Does anybody here know how the Seamonkey project is going to deal with
Mozilla's disposal of XUL?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Rainer Weikusat]

Didier Kryn  writes:

[...]

>> A multi-line version could look like this:
>>
>> while (c = *r) {
>>  ++r;
>>  if (c == '/') n = r;
>> }
>>
>
> It might be done with a for loop.  eg:
>
> for ( ; *r ; ++r) if(*r=='/') n=r;
> n++;

[...]

> The for loop is the best construct for a loop with an incremental
> cursor.

That's nicely exemplified by the fact that the code above does a
redundant increment (or did a redundant increment would it work, the {}
are missing) solely to work around the fact that the "for loop
mechanics" of checking the condition before the loop body is executed
and performing a "variable increment step" afterwards are ill-suited to
this particular problem ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd-free.org

[dev1fanboy]

Although I'm no fan of rolling release distros, it's good to know there is some 
effort to preserve other inits there.

On Monday, January 25, 2016 3:47 PM, Jaromil  wrote:
> re all,
> 
> here a new initiative by brothers and sisters of ArchLinux, one of the
> first distributions to be bullied into systemd http://systemd-free.org
> 
> ArchLinux is a relatively young and very sharp distribution, they have
> arguably the best documentation wiki on-line on GNU/Linux matters and
> many smart people among their developers, some well known to us at
> dyne.org.
> 
> This initiative is worth following I believe, especially for those of us
> who are intentioned in stepping over to OpenRC, since that seems to be
> the direction they are taking.
> 
> ciao
> 
> --
> Denis Roio aka Jaromil   http://Dyne.org think  tank
>   CTO and co-founder  free/open source developer
> 加密  6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Lightweight media/video player

[Mitt Green]

Hi,

As I recently have been playing with window managers,
mostly FVWM, i3 and now it's Openbox, to latter I switched
from Xfce because I have decided not to go with D-Bus,
I am now in need to find a lightweight media or, precisely,
video player.

In Xfce I had been using Parole, because it's lightweight,
but it, as well as other Xfce components, depends on D-Bus
via Xfconf.

All these xmms2, mplayer, smplayer pull about 50 additional
packages, which is huge, comparing to parole, that wants to
install just ten more.

By lightweight I mean:
- GTK+2 or even CLI interface (GTK+3 is less favoured);
- not a lot of dependencies (why do I need to install
samba-libs to decode videos, I don't know);
- it would be great if a player is already compiled in .deb and
is in repos/PPA/official site.

Thank you all,


Have a good one,
//  Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian is endorsed by Microsoft

[Arnt Karlsen]

On Fri, 22 Jan 2016 01:29:06 +0100, Wim wrote in message 

Re: [DNG] Lightweight media/video player

[dev1fanboy]

One of the better ones for the purpose of keeping pulse and dbus out is xine 
(xine-ui). As far as a media player.. I think it's best to have one thing for 
music and another for video. A good music player is cmus which uses ncurses and 
has playlist support, does not use any crappy extra libs, no dbus or pulse. 

For most media players you can just expect them to pretty much link into every 
audio plugin and even libsdl or gstreamer eventhough the former makes that 
useless. 

mplayer2 has no dbus but does have libpulse0.

On Monday, January 25, 2016 6:04 PM, Mitt Green  wrote:
> Hi,
> 
> As I recently have been playing with window managers,
> mostly FVWM, i3 and now it's Openbox, to latter I switched
> from Xfce because I have decided not to go with D-Bus,
> I am now in need to find a lightweight media or, precisely,
> video player.
> 
> In Xfce I had been using Parole, because it's lightweight,
> but it, as well as other Xfce components, depends on D-Bus
> via Xfconf.
> 
> All these xmms2, mplayer, smplayer pull about 50 additional
> packages, which is huge, comparing to parole, that wants to
> install just ten more.
> 
> By lightweight I mean:
> - GTK+2 or even CLI interface (GTK+3 is less favoured);
> - not a lot of dependencies (why do I need to install
> samba-libs to decode videos, I don't know);
> - it would be great if a player is already compiled in .deb and
> is in repos/PPA/official site.
> 
> Thank you all,
> 
> 
> Have a good one,
> //  Mitt
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Lightweight media/video player

[dev1fanboy]

Also forgot to mention cdcd can play music direct from a cd. One tool one job 
and all that, I also noted there are some more audio video/players around but 
some of them are targetted to a specific purpose, like smpeg-gtv for playing 
mpegs.

On Monday, January 25, 2016 6:04 PM, Mitt Green  wrote:
> Hi,
> 
> As I recently have been playing with window managers,
> mostly FVWM, i3 and now it's Openbox, to latter I switched
> from Xfce because I have decided not to go with D-Bus,
> I am now in need to find a lightweight media or, precisely,
> video player.
> 
> In Xfce I had been using Parole, because it's lightweight,
> but it, as well as other Xfce components, depends on D-Bus
> via Xfconf.
> 
> All these xmms2, mplayer, smplayer pull about 50 additional
> packages, which is huge, comparing to parole, that wants to
> install just ten more.
> 
> By lightweight I mean:
> - GTK+2 or even CLI interface (GTK+3 is less favoured);
> - not a lot of dependencies (why do I need to install
> samba-libs to decode videos, I don't know);
> - it would be great if a player is already compiled in .deb and
> is in repos/PPA/official site.
> 
> Thank you all,
> 
> 
> Have a good one,
> //  Mitt
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evolution of a Unix minimalist

[Teodoro Santoni]

2016-01-25 21:21 GMT+01:00, Mitt Green :
> Removes GNOME3
>
> Removes systemd
>
> Removes Xfce
> Removes 9wm
>
> Removes X
>
> Removes their package manager
> Removes make, because "I can cc everything by myself"
>
> Removes C++ programmes
> Removes C programmes
>
> "Why do I need Assembly when there is machine code"

Removes ATA controller because it's using statistical models of
butterfly flying for writing on their hard disk [0].

I think there it's nothing wrong with it, too.

[0] https://xkcd.com/378/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evolution of a Unix minimalist

[Rainer Weikusat]

Mitt Green  writes:
> Removes GNOME3
>
> Removes systemd
>
> Removes Xfce
> Removes 9wm
>
> Removes X
>
> Removes their package manager
> Removes make, because "I can cc everything by myself"
>
> Removes C++ programmes
> Removes C programmes
>
> "Why do I need Assembly when there is machine code"

Now, what to all of these have in common beyond "you got almost all of
the chronology wrong"?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evolution of a Unix minimalist

[dev1fanboy]

Reverse the order and change remove for installs and you have the evolution of 
linux into windows ;-)

On Monday, January 25, 2016 8:21 PM, Mitt Green  wrote:
> Removes GNOME3
> 
> Removes systemd
> 
> Removes Xfce
> Removes 9wm
> 
> Removes X
> 
> Removes their package manager
> Removes make, because "I can cc everything by myself"
> 
> Removes C++ programmes
> Removes C programmes
> 
> "Why do I need Assembly when there is machine code"
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evolution of a Unix minimalist

[Florian Zieboll]

On Mon, 25 Jan 2016 21:06:45 +
Rainer Weikusat  wrote:

> Now, what to all of these have in common beyond "you got almost all of
> the chronology wrong"?


Definitely the "Head or tails", gentlemen ;)

Quote from: 
Asimov, Isaac - The Machine That Won The War, 1961 (filetype:pdf)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Rainer Weikusat]

Peter Olson  writes:
>> On January 25, 2016 at 7:40 AM KatolaZ  wrote:
>> On Mon, Jan 25, 2016 at 12:23:01PM +, Rainer Weikusat wrote:

[...]

>> > static char const *get_name(char const *arg0)
>> > {
>> > char const *n, *r;
>> > 
>> > n = r = arg0;
>> > while (*r) if (*r++ == '/') n = r;
>> > return n;
>> > }
>> 
>> That's pretty straight-forward C-programming, IMHO, but I agree that
>> it could be seen as interesting by a mor^H^H^Hstudent who approaches C
>> for the first time.

[...]

> This also brings up the question of whether you should roll your own get_name 
> or
> use basename(3) which already

[...]

A related but IMHO more interesting set of questions could be:

1. Should every trivial crap $someone ever implemented since 1978 end up
   in general purpose library just because $someone happend to have to
   power to put it into it?

2. Should people be required to memoize every trivial crap $someone ever
   implemented since 1978 just because that someone happened to have to
   power to ...?

3. Should people who consider themselves Very Superior Entities because
   the have memoized every trivial crap $someone ever ... and so on, be
   taken as seriously as they continuously demand?
   
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Didier Kryn]

Le 25/01/2016 23:44, Peter Olson a écrit :

This also brings up the question of whether you should roll your own get_name or
use basename(3) which already does the same thing except in some edge cases.
  It's easier for the student to understand the code if it is implemented as
get_name, but the student ought to learn about dirname and basename pretty early
in their study.


Using basename() and dirname(0 haven't the power to trigger an 
interesting discussion :-)


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Didier Kryn]

Le 25/01/2016 19:11, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]


A multi-line version could look like this:

while (c = *r) {
++r;
  if (c == '/') n = r;
}


 It might be done with a for loop.  eg:

 for ( ; *r ; ++r) if(*r=='/') n=r;
n++;

[...]


The for loop is the best construct for a loop with an incremental
cursor.

That's nicely exemplified by the fact that the code above does a
redundant increment (or did a redundant increment would it work, the {}
are missing)
There needs only be one increment of n at the end of the loop, but, 
maybe it should be:

if(n) n++;
because I guess n starts from 0.

  solely to work around the fact that the "for loop
mechanics" of checking the condition before the loop body is executed
and performing a "variable increment step" afterwards are ill-suited to
this particular problem ...



I must agree, and I didn't think it was true before reading your 
example, that the post-increment may have a true semantic value beyond 
an attempt to optimise execution which would be futile. Which doesn't 
mean I'm convinced it :-)


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater

[Rainer Weikusat]

Rainer Weikusat  writes:
> Didier Kryn  writes:
>
> [...]
>
>>> A multi-line version could look like this:
>>>
>>> while (c = *r) {
>>> ++r;
>>>  if (c == '/') n = r;
>>> }
>>>
>>
>> It might be done with a for loop.  eg:
>>
>> for ( ; *r ; ++r) if(*r=='/') n=r;
>> n++;
>
> [...]
>
>> The for loop is the best construct for a loop with an incremental
>> cursor.
>
> That's nicely exemplified by the fact that the code above does a
> redundant increment (or did a redundant increment would it work, the {}
> are missing) solely to work around

[...]

>  the "for loop

While making fun of other people's statements in this way may be ... well
... fun, it's not very nice and also not exactly useful.

A C 'for loop' is a pretty strange control construct (one could call it
'overly generic'). It's definition (from K 2nd ed) is

for (expression1; expression2; expression3) statement
   
is equivalent to

expression1;
while (expression2) {
  statement
  expression3;
}

[in absence of a continue in 'statement']

That's a generalization of a loop with the abstract structure

;
while () {
;
;
}

with


Sequence of statements intializing a set of loop control
variables.


Test expression. Used to compare loop control variables or
values depending on loop control variables with a termination
condition (or 'continuation condition' for C). If the loop
should execute once more, the

,
a sequence of statements making up the loop body, are
executed. These may perform operation depending on the current
value of loop control variables but don't modify them
themselves.


Sequence of statements changing the loop control variables
possibly based on results from the  to 'the next
state' prior to evualting the  again.

but the C for (;;;) doesn't enforce any of these semantic conventions
but is really more of a macro which tranposes the text inside the (;;;)
as indicated above. Each of the expressions of a for (;;;) may contain
arbitrary C expressions, ie, anything except C control constructs.

If one happens to be writing a loop following the abstract description
given above, for (;;;) can be used to express it fairly
straight-forwardly if it isn't too complicated. The 'classic' example
would be the C-approximation of a counting loop,

for (int i = 0; i < 10; i++) printf("%d\n", i);

But the loop in

static char const *get_name(char const *arg0)
{
char const *n, *r;

n = r = arg0;
while (*r) if (*r++ == '/') n = r;
return n;
}

is not of this type. It contains an init-statement,

n = r = arg0;

followed by a test expression,

while (*r)

followed by another test of the same value,

if (*r == '/')

followed by a step-statement,

if (*r++ == '/)

followed by an assignment which should only be executed if the test was
true but which should use the value modified by the step expression.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Readable code; making code more easily writable; Emacs, multifiles-apmod; VUE; Code Bubbles; Lisp; Inform 7; HyperCard and HyperTalk - was Re: "Common knowledge?"-question

[Apollia]

On Sun, Jan 24, 2016 at 4:08 PM, Rainer Weikusat <
rainerweiku...@virginmedia.com> wrote:

> Apollia  writes:
>
> [...]
>
> > I think if I ever did code much in C, my code would end up looking very
> > unusual and unconventional to many people, because I often like to use
> > long, descriptive names for functions and variables, no matter what
> > language I'm using, even Bash.
>
> This style isn't really uncommon for people used to IDEs doing
> identifier auto-completion. But that's not only a bitch to work with
> without it but also difficult to read because of the sheer verbosity of
> the text. Eg, using an identifier
>
> combined-list-of-files-in-all-source-folders
>
> doesn't really communicate more than 'all-files' or even just 'all' (if
> the files is evident from the context) would.
>

Thanks for the feedback!  Perhaps as I get more comfortable with
programming in general I'll stop relying so much on the crutch of overly
verbose names.  I know I overdo it to some extent.

But another thing I like about long, unique, non-generic names is that when
doing searches, I can more easily find definitely related pieces of code,
and avoid finding a lot of unrelated pieces of code which just happen to
use the same generic variable names like "x" or "all".


If I were a painter instead of a coder, perhaps I might be more of an
impressionist than a realist or a minimalist.  But even that might be too
complimentary of my style. :-)  Rather than impressionist, I'm maybe more
of a hasty, impatient finger-painter specializing in abstract blobs. :-)
Or a caricaturist who exaggerates many things ridiculously. :-)

But, hopefully I'll learn to do better after plenty more practice, and
continuing to strive to learn as much as I can from wiser and more
knowledgeable people than me, such as you and probably everyone here.

I'm probably going to go back to being mostly quiet now since I can't think
of much else of interest to add.

But, thanks to you and everyone for all your fascinating, very educational
posts, and all the wonderful work you're all doing on Devuan!

Best wishes,
Apollia
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Icerbergs aren't small just because they're mostly underwater (was: "Common knowledge?"-question)

[Peter Olson]

> On January 25, 2016 at 7:40 AM KatolaZ  wrote:
> 
> 
> On Mon, Jan 25, 2016 at 12:23:01PM +, Rainer Weikusat wrote:
> > KatolaZ  writes:
> > 
> > [...]

 [...]

> > The program also contains a very nice example of why the post-increment
> > operators is useful (and I means 'useful', not 'common because of
> > mindless copying of example code'):
> > 
> > static char const *get_name(char const *arg0)
> > {
> > char const *n, *r;
> > 
> > n = r = arg0;
> > while (*r) if (*r++ == '/') n = r;
> > return n;
> > }
> 
> That's pretty straight-forward C-programming, IMHO, but I agree that
> it could be seen as interesting by a mor^H^H^Hstudent who approaches C
> for the first time.
> 
> Peace, love and hacking.
> 
> KatolaZ

This also brings up the question of whether you should roll your own get_name or
use basename(3) which already does the same thing except in some edge cases.
 It's easier for the student to understand the code if it is implemented as
get_name, but the student ought to learn about dirname and basename pretty early
in their study.

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Didier Kryn]

Le 24/01/2016 19:14, KatolaZ a écrit :

Soo, the above is nearly the same as
>
>   char buf[total];
>   p = buf;
>
>Why then use alloca()?
>

Maybe because
  
   char buf[total];


works only in ANSI C11. I still don't see the need for an internal
buffer to print out a formatted string, to be honest:)


The following works in plain old C:

#include 
#include 
static void print_start(char const *name, char const *what)
{
 unsigned name_len, what_len, total;

 name_len = strlen(name);
 what_len = strlen(what);
 total = name_len + what_len + 3;
 {
   char buf[total], *p=buf;
   memcpy(p, name, name_len);
   p += name_len;
   *p++ = ' ';
   memcpy(p, what, what_len);
   p += what_len;
   *p++ = ':';
   *p = ' ';
   *buf &= ~0x20;

   Write(2, buf, total);
 }
}

Embedded subprograms have other use cases. In long programs, they 
allow to declare variables with a limited scope, just near where they 
are used.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[KatolaZ]

On Mon, Jan 25, 2016 at 09:27:15AM +0100, Didier Kryn wrote:

[cut]

> 
> The following works in plain old C:
> 
> #include 
> #include 
> static void print_start(char const *name, char const *what)
> {
>  unsigned name_len, what_len, total;
> 
>  name_len = strlen(name);
>  what_len = strlen(what);
>  total = name_len + what_len + 3;
>  {
>char buf[total], *p=buf;
>memcpy(p, name, name_len);
>p += name_len;
>*p++ = ' ';
>memcpy(p, what, what_len);
>p += what_len;
>*p++ = ':';
>*p = ' ';
>*buf &= ~0x20;
> 
>Write(2, buf, total);
>  }
> }
> 
> Embedded subprograms have other use cases. In long programs,
> they allow to declare variables with a limited scope, just near
> where they are used.

I would say that having embedded subprograms in a function is not the
best thing one can do in C, but that's maybe a matter of preference :)

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Didier Kryn]

Le 25/01/2016 11:34, KatolaZ a écrit :

I would say that having embedded subprograms in a function is not the
best thing one can do in C


Every block is a subprogram. The block in a do loop, the 
conditional block in an if or while statement. The subprogram blocks are 
everywhere in C; they're a basic construct of the language. I don't see 
why plain blocks woud be bad, ie neither conditional, nor loop. And I 
also consider a sane practice to restrict the scope of variables as much 
as it makes sense.


It's just that there are two features that most C programmers never 
learn or quickly forget:


1) blocks don't need to be conditional or loop,
2) they can contain declarations.

On the contrary, the ability to declare variables outside of a 
block, in the middle of instructions, like in C++ is a nonsense; it is 
an incitation to loose programming.


I personnally re-discovered this very nice features a few years ago 
after having used the equivalent in Ada.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Dr. Nikolaus Klepp]

Am Montag, 25. Januar 2016 schrieb KatolaZ:
> On Mon, Jan 25, 2016 at 09:27:15AM +0100, Didier Kryn wrote:
> 
> [cut]
> 
> > 
> > The following works in plain old C:
> > 
> > #include 
> > #include 
> > static void print_start(char const *name, char const *what)
> > {
> >  unsigned name_len, what_len, total;
> > 
> >  name_len = strlen(name);
> >  what_len = strlen(what);
> >  total = name_len + what_len + 3;
> >  {
> >char buf[total], *p=buf;
> >memcpy(p, name, name_len);
> >p += name_len;
> >*p++ = ' ';
> >memcpy(p, what, what_len);
> >p += what_len;
> >*p++ = ':';
> >*p = ' ';
> >*buf &= ~0x20;
> > 
> >Write(2, buf, total);
> >  }
> > }
> > 
> > Embedded subprograms have other use cases. In long programs,
> > they allow to declare variables with a limited scope, just near
> > where they are used.
> 
> I would say that having embedded subprograms in a function is not the
> best thing one can do in C, but that's maybe a matter of preference :)
> 
> HND
> 
> KatolaZ
> 

What about making the source smaller and not the executable?

static void print_start(char const *name, char const *what) {
 if (name[0]) fprintf("%c%s",name[0]&~0x20, name+1);
 fprintf(stderr, " %s: ",what);
}

I know this is not slim, but as maintenance time rises with 
pow(lines-of-code,something>1.0), it pays quite soon :-)

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[KatolaZ]

On Mon, Jan 25, 2016 at 12:18:09PM +0100, Dr. Nikolaus Klepp wrote:

[cut]

> 
> What about making the source smaller and not the executable?
> 
> static void print_start(char const *name, char const *what) {
>  if (name[0]) fprintf("%c%s",name[0]&~0x20, name+1);
>  fprintf(stderr, " %s: ",what);
> }
> 
> I know this is not slim, but as maintenance time rises with 
> pow(lines-of-code,something>1.0), it pays quite soon :-)

+1

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Rainer Weikusat]

Didier Kryn  writes:
> Le 24/01/2016 19:14, KatolaZ a écrit :
>>> Soo, the above is nearly the same as
>>> >
>>> >   char buf[total];
>>> >   p = buf;
>>> >
>>> >Why then use alloca()?
>>> >
>> Maybe because
>>  char buf[total];
>>
>> works only in ANSI C11. I still don't see the need for an internal
>> buffer to print out a formatted string, to be honest:)
>
> The following works in plain old C:
>
> #include 
> #include 
> static void print_start(char const *name, char const *what)
> {
>  unsigned name_len, what_len, total;
>
>  name_len = strlen(name);
>  what_len = strlen(what);
>  total = name_len + what_len + 3;
>  {
>char buf[total], *p=buf;

It works if the compiler supports the VLA (variable-length array)
feature introduced with C99. But besides apparently aesthetically
pleasing to certain people, it doesn't offer anything which alloca
doesn't offer as well and doesn't offer some things the latter does, eg,
allocating structures which will end up being linked together via
pointers.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] "Common knowledge?"-question

[Rainer Weikusat]

"Dr. Nikolaus Klepp"  writes:

[...]

> What about making the source smaller and not the executable?
>
> static void print_start(char const *name, char const *what) {
>  if (name[0]) fprintf("%c%s",name[0]&~0x20, name+1);
>  fprintf(stderr, " %s: ",what);
> }

Are you seriously convinced that - in 2016 - there are still people who
haven't heard of the stdio library introduced with the 7th edition of
UNIX(*)?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Icerbergs aren't small just because they're mostly underwater (was: "Common knowledge?"-question)

[Rainer Weikusat]

KatolaZ  writes:

[...]

>  I still don't see the need for an internal buffer to print out a
>  formatted string, to be honest :)

Everything in code can always be implemented in a number of different
ways, hence, whatever the code ends up doing is "not really needed" ---
it could have achieved the same in a different way.

In this case, the function is part of a 79 lines program whose main
looks like this:

int main(int argc, char **argv)
{
char const *name;
int status;

name = get_name(*argv);
openlog(name, LOG_PID | LOG_PERROR, LOG_DAEMON);
if (argc < 3) usage();

print_start(name, argv[1]);

switch (fork()) {
case -1:
die(__func__, "fork");

case 0:
execvp(argv[2], argv + 2);

syslog(LOG_ERR, "main: execvp: %m(%d)", errno);
_exit(1);
}

wait();
print_stop(status);

return 0;
}

and whose purpose is to enable me to write

starting "unleashed VPN" \
daemon -n chdir / monitor -n qvpn ssh-vpn mes-pgsql 5000 unleashed 
unleashed4

in an init script to get a 'start: ok (or failed)' message printed to
file descriptor 2 with having to put two printf invocation around the
start command. And in the context of that, using stdio for the sole
purpose of performing a trivial string formatting operation seemed very
inappropriate --- that's new-fangled, ill-thought out stuff supposed to
make UNIX(*) easier to use by moron^WUCB students and who really needs
that?

The program also contains a very nice example of why the post-increment
operators is useful (and I means 'useful', not 'common because of
mindless copying of example code'):

static char const *get_name(char const *arg0)
{
char const *n, *r;

n = r = arg0;
while (*r) if (*r++ == '/') n = r;
return n;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Lightweight media/video player

[Hughe Chung]

I started using mpv as media player instead vlc. vlc has become unstable 
often producing segmentation fault, skipping frames. The package names 
is mpv.


It has tiny package size less than 1.5 MB.

$ mpv --version
mpv 0.8.3 (C) 2000-2015 mpv/MPlayer/mplayer2 projects
 built on Tue Mar 17 06:56:30 UTC 2015
ffmpeg library versions:
   libavutil   54.20.100
   libavcodec  56.26.100
   libavformat 56.25.101
   libswscale  3.1.101
   libavfilter 5.11.102
   libswresample   1.1.100

The user can modify or add key bindings using the configuration file 
~/.config/mpv/input.conf


I downloaded input.conf file from
https://raw.githubusercontent.com/mpv-player/mpv/master/etc/input.conf

I added two key bindings to reduce the window size like below, moved the 
input.conf file to ~/.config/mpv/ directory.


#5 add gamma -1
#6 add gamma 1
#7 add saturation -1
#8 add saturation 1
Alt+0 set window-scale 0.5
Alt+1 set window-scale 0.75
#Alt+2 set window-scale 2.0


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng