Re: [Musicpd-dev-team] Other features for mpc

2010-01-06 Thread Jeff Frasca
On Wed, 6 Jan 2010, Max Kellermann wrote:

 No need to sort, MPD has a defined sorting order for songs:

 http://git.musicpd.org/cgit/master/mpd.git/tree/src/songvec.c#n92

Ok, so I'm running the mpd stable package, I was on 0.15.6, but 0.15.7
has the same (old) songvec_cmp() which compares on TAG_ITEM_DISC,
TAG_ITEM_TRACK and finally on filename.  When I grabbed the git
repository, songvec_cmp() was correct.

The commit for that fix was on 31 Oct 2009.  0.15.6 was released in
November and 0.15.7 was released a week and a half ago.  Is there a good
reason this isn't in either of the stable tarballs?

 So there's no mingw32 package for Slackware?  In this case, it's
 enough to just test the build, because most portability problems
 appear at built time and not at run time.

Nope.  It's not in the base distro, and Slackware has a culture of If 
you want something weird, you can build it yourself (under that 
assumption, the base packages for libraries include header files).  So, 
sometimes there are third party packages, but more often than not, they
don't exist.

Jeff

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-06 Thread Max Kellermann
On 2010/01/06 20:15, Jeff Frasca phaed...@u.washington.edu wrote:
 Ok, so I'm running the mpd stable package, I was on 0.15.6, but 0.15.7
 has the same (old) songvec_cmp() which compares on TAG_ITEM_DISC,
 TAG_ITEM_TRACK and finally on filename.  When I grabbed the git
 repository, songvec_cmp() was correct.

 The commit for that fix was on 31 Oct 2009.  0.15.6 was released in
 November and 0.15.7 was released a week and a half ago.  Is there a good
 reason this isn't in either of the stable tarballs?

Yes, you weren't viewing the stable branch (v0.15.x).  That's the
technical reason, not necessarily a good reason.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Jeffrey Middleton
I'm not too sure about the globbing question at first glance.  However,
refining ambiguous completion seems a prime candidate for placing inside
mpc. If you filter afterwards with a script, you're wasting time querying
for information you then waste time throwing away, while mpc could easily
just only list the necessary directories then exit.

Jeffrey
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Max Kellermann
On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote:
 When done in the completer code, it requires two extra fork()/exec()s of  
 the sed and sort code.  The sed and sort code are more general than we  
 would write, but they are also already debugged, and not that much more  
 overhead for something that runs no more than once or twice in a second, 
 and then only occasionally.

mpc used to have (or still has?  I'm not sure) special commands for
the bash completion.  That should be avoided if possible, because mpc
shouldn't be bloated with interactive features.  mpc isn't supposed to
be an interactive client, and I think bash+sed (as you said) might be
well enough for implementing the completion.

If something is really missing in mpc, and you come to the conclusion
that the completion can be optimized with a new mpc command, then this
command should be designed in a generic way (if possible), to make it
reusable for other mpc users.

Note that I don't use the completion code, I don't have an oponion on
that.  I'll merge patches from folks who do use it and like to care
about the code.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Jeffrey Middleton
On Tue, Jan 5, 2010 at 11:57 AM, Max Kellermann m...@duempel.org wrote:

 On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote:
  When done in the completer code, it requires two extra fork()/exec()s of
  the sed and sort code.  The sed and sort code are more general than we
  would write, but they are also already debugged, and not that much more
  overhead for something that runs no more than once or twice in a second,
  and then only occasionally.

 mpc used to have (or still has?  I'm not sure) special commands for
 the bash completion.  That should be avoided if possible, because mpc
 shouldn't be bloated with interactive features.  mpc isn't supposed to
 be an interactive client, and I think bash+sed (as you said) might be
 well enough for implementing the completion.


It still does have a tab and lstab command.

For a short-term solution, it sounds like the currently implemented 'tab'
command could be modified.  Currently, it lists everything, then sees if
each individual thing is a match to the given partial name.  It could
instead list the dirname of the partial name and check for matches to the
basename of the partial name. This wouldn't add a ton of bloat, it seems.

For long-term... Clearly Jeff uses mpc as an interactive client, and I do as
well sometimes; we're probably not the only ones.  Mpc is really quite close
to an ideal command-line interactive client already, so what's the best
approach for adding any desired interactive features?  It's not just an
additional few commands - stuff like the globbing mentioned earlier would
modify existing commands.

Jeffrey
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Jeff Frasca
On Tue, 5 Jan 2010, Max Kellermann wrote:

 On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote:
 When done in the completer code, it requires two extra fork()/exec()s of
 the sed and sort code.  The sed and sort code are more general than we
 would write, but they are also already debugged, and not that much more
 overhead for something that runs no more than once or twice in a second,
 and then only occasionally.

 mpc used to have (or still has?  I'm not sure) special commands for

Still has.  'mpc tab' is the interesting one here (used to complete
'mpc add').

 the bash completion.  That should be avoided if possible, because mpc
 shouldn't be bloated with interactive features.  mpc isn't supposed to
 be an interactive client, and I think bash+sed (as you said) might be
 well enough for implementing the completion.

mpc is my main client.  However, I agree on the minimalist approach
to the code (that's why I like it).

So, right now, cmd_tab() sends the listall command like this:

 if (!mpd_send_list_all(conn, ))
printErrorAndExit(conn);

The  is the directory to list, so this could be made significantly
smarter by supplying the directory.  It took me 11 LoC (counting blank
lines and closing brackets).  It doesn't change the behavior with
the current completer code--the items that get culled by the server
would have been culled by the client.

However, that change merely cuts down the traffic over the socket for
subsequent tab mashes.  Any tab mash in the top-level directory is just
as expensive as before.

It also doesn't get me what I want (list only the entries in the current
directory level).  That would require significantly more C code or the
extra bash+sed that I'm already using.

 If something is really missing in mpc, and you come to the conclusion
 that the completion can be optimized with a new mpc command, then this
 command should be designed in a generic way (if possible), to make it
 reusable for other mpc users.

Right.  OTOH, my other feature idea--globbing or regex in 'mpc add'
makes the command significantly more complex.  I ended up writing a
mockup of the functionality by adding an 'mpc radd' code (so mpc add
continues to work exactly as before--thus not breaking any scripts).
'mpc radd' is more of an interactive type feature, but I know at least
one other person on the list wants it.

(All the code is still sitting on my harddrive, I haven't pushed any of
it yet.)

Jeff

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Max Kellermann
On 2010/01/05 19:51, Jeff Frasca phaed...@u.washington.edu wrote:
 However, that change merely cuts down the traffic over the socket for
 subsequent tab mashes.  Any tab mash in the top-level directory is just
 as expensive as before.

That's already a big improvement.

 It also doesn't get me what I want (list only the entries in the current
 directory level).  That would require significantly more C code or the
 extra bash+sed that I'm already using.

mpc ls foo/bar

I've never understood why the completion code didn't use this very
basic command.

 Right.  OTOH, my other feature idea--globbing or regex in 'mpc add'
 makes the command significantly more complex.  I ended up writing a
 mockup of the functionality by adding an 'mpc radd' code (so mpc add
 continues to work exactly as before--thus not breaking any scripts).
 'mpc radd' is more of an interactive type feature, but I know at least
 one other person on the list wants it.

Ok, let's say we add a compile-time option to disable interactive
commands (like ncmpc's --enable-mini option?).  Those on tiny embedded
systems will have the choice.  This would raise my personal limit for
accepting bloaty mpc patches significantly.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] Other features for mpc

2010-01-05 Thread Jeff Frasca
On Tue, 5 Jan 2010, Max Kellermann wrote:

 src/command.c:943: error: initialization discards qualifiers from
 pointer target type

 Compile with --enable-werror, please.  The code should be warning
 clean.

Fixed.  Same spot.  Configuring with --enable-werror from now on.

 The tab command should be disabled with --enable-mini.  It's unlikely
 to be useful on those tiny platforms.

Will do.

Jeff

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team