Re: [Musicpd-dev-team] [RFC-for-post-0.14] [PATCH] Support RVA2 Tags

2008-11-26 Thread Max Kellermann
On 2008/11/24 01:58, Avuton Olrich [EMAIL PROTECTED] wrote:
 This is the first in a series of patches I hope to do to update from
 patches in from our bug tracker. I hope as well to get comments, and
 the community gives these concepts and patches the big ACK or NACK. I
 will try to keep these patches up to date until they're either
 accepted or given the NACK, at which time I'll pop it off my guilt and
 close the bug. Most of these patches I have neutral feelings about
 acceptance. I may attempt to provide new better versions with
 criticism though, please keep in mind that I am not a developer.

On this particular patch: it looks like a useful extension, but I
havn't had enough time yet to give it an in-depth review.

In general, I think it is a very good idea to collect patches in a git
repository - the Linux kernel people have a linux-staging and a
linux-next tree, a similar concept.  Currently, our master
repository is frozen, due to beta testing.  After 0.14 is released, we
will be able to continue quickly if we can simply pick patches from
your repository - good work again, Avuton.

Two things should be optimized:

1.) give credit to contributors.  The patch's author should reflect
the name of whoever has written it in the first place, even if we
changed some lines for proper merging into the current code base.

2.) if possible, don't merge (pull) from master, rebase instead
(pull --rebase).  This results in some more maintenance work
because you have to merge conflicts, but it ensures that the new
patches always match the current master code base.

Max

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


[Musicpd-dev-team] Night of Pleasuure

2008-11-26 Thread Bronikowski Mcmunn

Are you ready for Chrisstmas night? ;)
http://cid-35c873b0a2b4deb2.spaces.live.com/blog/cns!35C873B0A2B4DEB2!106.entry




Were either reflected or defeated and there was certain extent,
the victim of heredity. He had but she did not why did you
say that miss grey but your nursing would not make much
difference, whaur ye are, laird, she said i'll gang doon,.  -
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


[Musicpd-dev-team] The libmpdclient v2.0 project

2008-11-26 Thread Max Kellermann
Hi,

the libmpdclient project has suffered in the past: instead of having a
shared library with a stable API, all clients chose to copy
libmpdclient.c into their source directory.  That resulted in many
forked and different versions of libmpdclient.

To fix that, to account for new requirements and to support new MPD
features (e.g. idle), I decided to start the project libmpdclient
v2.0.  Although there never was a 1.0, 2 will be the SO version
(i.e. libmpdclient.so.2).

The goals of the project:

- provide a slim and fast C API for connecting to MPD
- no dependencies except C99/POSIX (maybe compile-time optional GLib
  for memory slices, etc.)
- portability - even Windows?  There's no good C99 compiler on
  Windows..  mingw32?
- consume few resources
- API is lean, but powerful
- very low-level (i.e. stateless)
- maybe provide a second, high-level library (merge code from libmpd?)
- maybe provide a C++ OO API (merge code from ncmpcpp?)
- support asynchronous (=non-blocking) I/O, but don't mandate a
  framework (libevent, GLib)
- keep support for synchronous (=blocking) I/O (with timeout?)
- support all MPD features, including idle

I have started to work on the current libmpdclient.git, and merged a
lot of patches from ncmpc.

 http://git.musicpd.org/cgit/cirrus/libmpdclient.git

Some of you already promised to help me with that.  From now on, I
will accept patches (git pull requests preferred).  Please keep your
git repository rebased on mine.

First TODO list fragment:
- remove CamelCase
- struct forward-declarations instead of typedefs
- make structs opaque
- separate libmpdclient.c into separate sub-libraries
- rename includes with mpd/ prefix: mpd/client.h mpd/song.h ...
-  much more

Max

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] The libmpdclient v2.0 project

2008-11-26 Thread Marc Pavot
 - portability - even Windows?  There's no good C99 compiler on
  Windows..  mingw32?

Just a quick remark about this point: I compile Ario and libmpdclient on
windows with mingw32 and it works fine. (I distribute .exe files for Ario).
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] The libmpdclient v2.0 project

2008-11-26 Thread Marc Pavot
 Some of you already promised to help me with that.  From now on, I
 will accept patches (git pull requests preferred).  Please keep your
 git repository rebased on mine.


I have created a git repository to help you on this project:
http://repo.or.cz/w/libmpdclient/marc.git

It is based on your repository and I have done one commit to continue the
split of libmpdclient.
It creates three new files: connection, idle and return_element. The
separation is not perfect (for example some structures and methods in
connection will have to become private in the future) but it's a first
brick.

Marc
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] The libmpdclient v2.0 project

2008-11-26 Thread Max Kellermann
On 2008/11/27 00:33, Marc Pavot [EMAIL PROTECTED] wrote:
 It is based on your repository and I have done one commit to continue the
 split of libmpdclient.
 It creates three new files: connection, idle and return_element. The
 separation is not perfect (for example some structures and methods in
 connection will have to become private in the future) but it's a first
 brick.

Thanks, it's merged.

I have some suggestions:

- I saw that your idle patch introduced inconsistent indentation
  (e.g. mpd_glibStartIdle); please configure your editor to indent
  with tabs.

- A commit should include a brief one-line description, followed by an
  empty line, and a longer description following.  This way, stuff
  like git shortlog works properly.  Don't write another description
  in the email - a well-documented patch doesn't need further
  explanation.

- set local includes first, to test if the include file has
  specified its own dependencies properly, i.e. include idle.h
  before stdio.h and string.h in idle.c.  In return_element.c you
  did this very well: return_element.h before str_pool.h
  (str_pool.h was already checked by str_pool.c).

Max

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team